System and method for implementing controller border gateway protocol (cBGP)

A method performed by a controller configured to implement Border Gateway Protocol (BGP) in a communications system, comprising establishing a controller BGP (cBGP) peer session with a network element (NE), receiving a message for communication through the cBGP session from the NE, determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information; transmitting the message to the NE through the cBGP session when the message is permitted to be communicated through the cBGP session, and receiving a response message of the first type from the NE through the cBGP session.

TECHNICAL FIELD

The present disclosure is generally related to network communications, and in particular, to various systems and methods for reducing the overhead in networks implementing Border Gateway Protocol (BGP).

BACKGROUND

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.

SUMMARY

A first aspect of the present disclosure relates to a method performed by a controller configured to implement Border Gateway Protocol (BGP) in a communications system, comprising establishing a controller BGP (cBGP) peer session with a network element (NE), receiving a message for communication through the cBGP session from the NE, determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information, transmitting the message of the first type to the NE through the cBGP peer session if the message is permitted to be communicated through the cBGP peer session, and receiving a response message of the first type from the NE through the cBGP peer session.

Optionally, in a first implementation according to the first aspect, the method further comprises receiving a second message for communication through the cBGP session from the NE, determining whether the second message is permitted to be communicated through the cBGP session based on whether the second message carries the routing information, and discarding the second message in response to the second message including the routing information.

Optionally, in a second implementation according to the first aspect or any other implementation of the first aspect, the routing information comprises information describing elements along a path from a source to a destination in the communications system.

Optionally, in a third implementation according to the first aspect or any other implementation of the first aspect, the method further comprises receiving a BGP UPDATE message carrying the routing information from another NE, and discarding the BGP UPDATE message.

Optionally, in a fourth implementation according to the first aspect or any other implementation of the first aspect, the method further comprises receiving a BGP UPDATE message carrying the routing information and instructions, removing the routing information from the BGP UPDATE message, and transmitting only the instructions of the BGP UPDATE message to the NE though the cBGP session.

Optionally, in a fifth implementation according to the first aspect or any other implementation of the first aspect, a 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, wherein the second type of message is a message carrying the routing information, wherein the controller and the NE are included in a common autonomous system (AS), wherein the method further comprises establishing an interior BGP (iBGP) session with the NE, wherein the iBGP session is separate and distinct from the cBGP session, and determining whether a second message received from the NE includes the routing information based on a format of the second message.

Optionally, in a sixth implementation according to the first aspect or any other implementation of the first aspect, a first type of message is a message carrying instructions, wherein a second type of message is a message carrying routing information, wherein the controller and the NE are included in a common autonomous system (AS), wherein the method further comprises establishing an interior BGP (iBGP) session with the NE, wherein the iBGP session is combined with the cBGP session, wherein the first type of message and the second type of message are permitted to be communicated through the combined session.

Optionally, in an seventh implementation according to the first aspect or any other implementation of the first aspect, a 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, wherein the second type of message is a message carrying the routing information, wherein the controller is included in a first autonomous system (AS), wherein the NE is included in a second AS different from the first AS, wherein the method further comprises establishing an exterior BGP (eBGP) session with the NE, wherein the eBGP session is separate and distinct from the cBGP session, and determining whether a second message received from the NE includes the routing information based on a format of the second message.

Optionally, in an eighth implementation according to the first aspect or any other implementation of the first aspect, a first type of message is a message carrying instructions, wherein a second type of message is a message carrying the routing information, wherein the controller is included in a first autonomous system (AS), wherein the NE is included in a second AS different from the first AS, wherein the method further comprises establishing an exterior BGP (eBGP) session with the NE, wherein the eBGP session is combined with the cBGP session, and wherein the first type of message and the second type of message are permitted to be communicated through the combined session.

Optionally, in a ninth implementation according to the first aspect or any other implementation of the first aspect, the method further comprising obtaining a peer group, wherein the peer group comprises a plurality of NEs, wherein the plurality of NEs include the NE, wherein a cBGP session is established between the controller and each of the plurality of NEs, receiving a third message comprising information of a first type from the NE, and distributing the third message to other NEs in the peer group in response to the information of the first type being permitted to be distributed to the other NEs in the peer group based on a peer group policy.

Optionally, in a tenth implementation according to the first aspect or any other implementation of the first aspect, the plurality of NEs in the peer group are grouped together based on at least one of a tenant identifier (ID), a geographical district, a zone, a group name, or encryption method.

Optionally, in a eleventh implementation according to the first aspect or any other implementation of the first aspect, establishing the cBGP session with the NE comprises sending a first OPEN message to the NE, wherein the first OPEN message comprises capabilities supported by the controller, and receiving a second OPEN message from the NE, wherein the second OPEN message comprises capabilities supported by the NE.

Optionally, in a twelfth implementation according to the first aspect or any other implementation of the first aspect, the first OPEN message comprises an I flag and a C flag, wherein the I flag is set to indicate whether an independent cBGP session is to be established or a combined cBGP session is to be established, wherein the C flag is set to indicate that the first OPEN message is sent by the controller.

Optionally, in a thirteenth implementation according to the first aspect or any other implementation of the first aspect, the controller is a Route Reflector (RR) within an autonomous system (AS).

A second aspect of the present disclosure relates to a method performed by a network element (NE) configured to implement Border Gateway Protocol (BGP) in a communications system, comprising establishing a controller BGP (cBGP) peer session with a controller of the communications system, receiving a message from the controller through the cBGP peer session, determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information, and transmitting a response message to the controller through the cBGP peer session.

Optionally, in a first implementation according to the second aspect, the method further comprises receiving a second message for communication through the cBGP session to the controller, determining whether the second message is permitted to be communicated through the cBGP session based on whether the second message carries the routing information, and discarding the second message in response to the second message including the routing information.

Optionally, in a second implementation according to the second aspect or any other implementation of the first aspect, the routing information comprises information describing elements along a path from a source to a destination in the communications system.

Optionally, in a third implementation according to the second aspect or any other implementation of the first aspect, the method further comprising receiving a BGP UPDATE message carrying the routing information from another NE, and discarding the BGP UPDATE message.

Optionally, in a fourth implementation according to the second aspect or any other implementation of the first aspect, the method further comprising receiving a BGP UPDATE message carrying the routing information and instructions, removing the routing information from the BGP UPDATE message, and transmitting only the instructions of the BGP UPDATE message to the controller through the cBGP session.

Optionally, in a fifth implementation according to the second aspect or any other implementation of the first aspect, a 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, wherein the second type of message is a message the carrying routing information, wherein the controller and the NE are included in a common autonomous system (AS), wherein the method further comprises establishing an interior BGP (iBGP) session with the controller, wherein the iBGP session is separate and distinct from the cBGP session, and determining whether a second message received from the controller includes the routing information based on a format of the second message.

Optionally, in a sixth implementation according to the second aspect or any other implementation of the first aspect, a first type of message is a message carrying instructions, wherein a second type of message is a message carrying the routing information, wherein the controller and the NE are included in a common autonomous system (AS), wherein the method further comprises establishing an interior BGP (iBGP) session with the controller, wherein the iBGP session is combined with the cBGP session, and wherein the first type of message and the second type of message are permitted to be communicated through the combined session.

Optionally, in an seventh implementation according to the second aspect or any other implementation of the first aspect, a 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, the first type of message is a message carrying instructions, wherein the second type of message is a message carrying the routing information, wherein the controller is included in a first autonomous system (AS), wherein the NE is included in a second AS different from the first AS, wherein the method further comprises establishing an exterior BGP (eBGP) session with the controller, wherein the eBGP session is separate and distinct from the cBGP session, and determining whether a second message received from the NE includes the routing information based on a format of the second message.

Optionally, in an eighth implementation according to the second aspect or any other implementation of the first aspect, a first type of message is a message carrying instructions, wherein a second type of message is a message carrying the routing information, wherein the controller is included in a first autonomous system (AS), wherein the NE is included in a second AS different from the first AS, wherein the method further comprises establishing an exterior BGP (eBGP) session with the NE, wherein the eBGP session is combined with the cBGP session, and wherein the first type of message and the second type of message are permitted to be communicated through the combined session.

Optionally, in a ninth implementation according to the second aspect or any other implementation of the first aspect, the plurality of NEs in the peer group are grouped together based on at least one of a tenant identifier (ID), a geographical district, a zone, a group name, or encryption method.

Optionally, in a tenth implementation according to the second aspect or any other implementation of the first aspect, establishing the cBGP peer session with the NE comprises sending a first OPEN message to the controller, wherein the first OPEN message comprises capabilities supported by the NE, and receiving a second OPEN message from the controller, wherein the second OPEN message comprises capabilities supported by the controller.

Optionally, in a eleventh implementation according to the second aspect or any other implementation of the first aspect, the first OPEN message comprises an I flag and a C flag, wherein the I flag is set to indicate whether an independent cBGP session is to be established or a combined cBGP session is to be established, wherein the C flag is set to indicate that the first OPEN message is not sent by the controller.

A third aspect of the present disclosure relates to an apparatus comprising a memory configured to store instructions, and a processor coupled to the memory and configured to execute the instructions, which when executed by the processor, causes the processor to be configured to establish a controller BGP (cBGP) peer session with a network element (NE), receive a message for communication through the cBGP session from the NE, determine whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information, transmit the message to the NE through the cBGP session if the message is permitted to be communicated through the cBGP session, and receive a response message of the first type from the NE through the cBGP session.

Optionally, in a first implementation of the third aspect, the instructions further causing the processor to be configured to receive a second message for communication through the cBGP session from the NE, determine whether the second message is permitted to be communicated through the cBGP session based on whether the second message carries the routing information, and discard the second message in response to the second message including the routing information.

A fourth aspect of the present disclosure relates to an apparatus comprising a memory configured to store instructions, and a processor coupled to the memory and configured to execute the instructions, which when executed by the processor, causes the processor to be configured to establish a controller BGP (cBGP) peer session with a controller of the communications system, receive a message from the controller through the cBGP session, determine whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information, and transmit a response message to the controller through the cBGP session.

Optionally, in a first implementation of the fourth aspect, the instructions further causing the processor to be configured to receive a second message for communication through the cBGP session to the controller, determine whether the second message is permitted to be communicated through the cBGP session based on whether the second message carries the routing information, and discard the second message in response to the second message including the routing information.

DETAILED DESCRIPTION

FIG.1is a diagram illustrating a communications system100configured to implement controller Border Gateway Protocol (cBGP) according to various embodiments of the disclosure. The communications system100includes two autonomous systems, AS103and AS106. The AS103includes NEs109and110, and the AS106comprises NEs111-115. InFIG.1, the NEs109-115are interconnected by links120-125. Links120and121are inter-domain links connecting NEs within a different AS103and AS106(e.g., NE111to NEs109and110). Links122-125are intra-domain links connecting NEs111-115within a single AS106.

NEs109-115may 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, NEs109-115are configured to implement BGP.

Links120-125may be wired or wireless links or interfaces interconnecting each of the NEs109-115and 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) 4271, entitled “A Border Gateway Protocol 4 (BGP-4),” by Y. Rekhter, et. al., dated January 2006 (hereinafter referred to as RFC 4271).

BGP sessions between NEs109-115in different ASs are referred as external BGP (eBGP) sessions or connections. For example, a BGP session between NE111and NE109or between NE111and NE110is 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 NE111and NE112and between NE111and NE113is an iBGP session. Two NEs109-115that have established an iBGP session are referred to as iBGP peers. Similarly, two NEs109-115that have established an eBGP session are referred to as eBGP peers.

InFIG.1, NE111is designated as a BGP Route Reflector (RR) for the communications system100, in which the NE111is directly or indirectly connected to the remaining NEs109-110and112-115of the communications system100. In an embodiment, the NE111implemented as the RR may be configured to act as a controller, or central entity, of the communications system100.

Within the communications system100, the NEs109-115are configured to communicate four different types of messages that are specified for BGP Version 4, as described by RFC 4271: 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 NE109-115sending 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 (2 octets), a withdrawn routes field (variable length), a total path attribute length field (2 octets), a path attributes field (variable length), and a NLRI field (2 octets).

The NLRI field is encoded as one or more 2-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 <16, 192.200.0.0> indicates network reachability information for the route 192.200.0.0/16. 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 NE109-115implementing iBGP or eBGP generates or receives routing information, such as in an UPDATE message, the NE109-115forwards the routing information to neighboring NEs109-115that also implement BGP. For example, when NE111transmits an UPDATE message carrying routing information of a certain path toward a destination to NE112, NE112is first configured to update a local routing table based on the UPDATE message when applicable to the NE112. Subsequently, NE112forwards 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, NEs109-115(or BGP peers) receive routing information via BGP messages, without having any use or need for the routing information. Therefore, these NEs109-115that receive unwanted routing information merely discard the routing information or forward the routing information to other NEs109-115, which may also not have any use or need for the routing information.

For this reason, NEs109-115implementing iBGP or eBGP flood network resources with these messages carrying routing information, even though several of the NEs109-115in the communications system100simply ignore or discard the message. In this way, communication systems implementing BGP, either iBGP and/or eBGP, typically 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 NE111establishes a cBGP session with NEs114and115. NEs111and114may be referred to herein as cBGP peers due to the cBGP session established between NE111and NE114. Similarly, NEs111and115may be referred to herein as cBGP peers due to the cBGP session established between NE111and NE115.

In this embodiment, NE111may only be permitted to communicate control messages to the NEs114and115through the cBGP session. For example, the control messages may include instructions that are sent to the NEs114and115. Similarly, NEs114and115are only permitted to transmit responses to the instructions or status information to the NE111through the cBGP session. In an embodiment, route information, such as the route information carried in an UPDATE message, is prohibited from being communicated between NE111and NEs114and115through the cBGP sessions.

For example, inFIG.1, NE111has established an eBGP session with NEs109and110, an iBGP session with NEs112and113, and a cBGP session with NEs114and115. In this case, when NE111receives routing information from one of the eBGP peers, such as NE109, NE111may forward the routing information to another eBGP peer (e.g., NE110), or an iBGP peer (e.g., one of NEs112or113). However, NE111is prohibited from forwarding the routing information to one of the cBGP peers (e.g., NEs114or115).

When NE111receives routing information from an iBGP peer as a client, such as NE112, NE111may forward the routing information to one of the eBGP peers (e.g., NEs109or110), the other iBGP peer (e.g., NE113), another iBGP client NE, or an iBGP non-client NE. However, NE111is prohibited from forwarding the routing information to one of the cBGP peers (e.g., NEs114or115).

When NE111receives routing information from an iBGP peer as a non-client, such as NE113, NE111may forward the routing information to one of the eBGP peers (e.g., NEs109or110), an eBGP client, the other iBGP peer (e.g., NE114), or an iBGP client. However, NE111is prohibited from forwarding the routing information to one of the cBGP peers (e.g., NEs114or115) or a non-client NE. In some cases, when NE111receives routing information from another iBGP peer (e.g., NEs112and113) or another eBGP peer (e.g., NEs109and110), 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 system100. In addition, the embodiments disclosed significantly reduce the amount of processing required to be performed by the cBGP peers within the communications system100.

FIG.2is a schematic diagram of an NE200suitable for implementing cBGP according to various embodiments of the disclosure. In an embodiment, the NE200may be implemented as any one of NEs109-115.

The NE200comprises ports220, transceiver units (Tx/Rx)210, a processor230, and a memory233. The processor230comprises a cBGP module224. Ports220are coupled to Tx/Rx210, which may be transmitters, receivers, or combinations thereof. The Tx/Rx210may transmit and receive data via the ports220. Processor230is configured to process data. Memory233is configured to store data and instructions for implementing embodiments described herein. The NE200may also comprise electrical-to-optical (EO) components and optical-to-electrical (OE) components coupled to the ports220and Tx/Rx210for receiving and transmitting electrical signals and optical signals.

The processor230may be implemented by hardware and software. The processor230may 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 processor230is in communication with the ports220, Tx/Rx210, and memory233. The cBGP module224is implemented by the processor230to execute the instructions for implementing various embodiments discussed herein. For example, the cBGP module224is 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 module224provides an improvement to the functionality of the NE200. The cBGP module224also effects a transformation of NE200to a different state. Alternatively, the cBGP module224is implemented as instructions stored in the memory233.

The memory233comprises 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 memory233may 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 memory233is configured to store a routing table260comprising routing information265. For example, routing information265includes information describing nodes or links along a path or tunnel to a destination. The routing table260includes routing information265for many different paths or tunnels. In an embodiment, the memory233is further configured to store instructions320, which are messages used to instruct another NE in a communications system100. In an embodiment, the instructions320are permitted to be communicated through a cBGP session. In an embodiment the memory233is further configured to store a peer group policy275and peer data280. A peer group policy275indicates a type of peer data280that can be shared between NEs of a peer group, as will be further described below with reference toFIGS.6and7.

FIG.3is a message sequence diagram illustrating a method300of establishing and implementing a cBGP session in the communications system100according to various embodiments of the disclosure. Method300is implemented by NEs109-115in the communications system100, such as NE111, NE112, and NE114. In an embodiment, NE111may be implemented as a controller or the RR of the communications system100. Method300is performed after an iBGP session as already been established between NE111and112, and after a Transmission Control Protocol (TCP) three-way handshake has been completed between NE111an NE114.

Upon completion of the TCP three-way handshake, NEs111and114attempt to establish a cBGP session using OPEN messages306and309. At step307, NE114populates and transmits an OPEN message306to NE111. The OPEN message306includes information describing that NE114should be negotiated and accepted by NE111before establishing a cBGP session between NE111and NE114. An OPEN message306includes a version of BGP that NE114is capable of implementing, an AS number of NE114, a hold down timer indicating a proposed number of seconds between messages, a BGP identifier indicating an identifier of the NE114, and one or more optional parameters. In an embodiment, the OPEN message306indicates whether NE114is capable of establishing a cBGP session. For example, the OPEN message306may include an optional capabilities field that includes a code indicating whether NE114is capable of establishing a cBGP session. In an embodiment, the capabilities field also indicates whether or not NE114is implemented or acting as the controller. As NE114is not implemented as the controller in this example, the capabilities field may indicate that NE114is not the controller.

At step310, NE111populates and transmits an OPEN message309to NE114. The OPEN message309is similar to the OPEN message306, except that the OPEN message309includes information describing NE111. The OPEN message309includes a version of BGP that NE111is capable of implementing, an AS number of NE111, a hold down timer indicating a proposed number of seconds between messages, a BGP identifier indicating an identifier of the NE111, and one or more optional parameters. In an embodiment, the OPEN message309indicates whether NE111is capable of establishing a cBGP session. For example, the OPEN message309may include an optional capabilities field that includes a code indicating whether NE111is capable of establishing a cBGP session. In an embodiment, the capabilities field also indicates whether or not NE111is implemented or acting as the controller. As NE111is implemented as the controller in this example, the capabilities field may indicate that NE111is the controller.

At steps313and316, the NEs114and111determine whether or not to establish a cBGP session between NEs114and111based on the information contained in the OPEN messages306and309. In particular, at step313, NE114determines whether the information and capabilities sent in the OPEN message306from NE111matches, or is compatible with, the capabilities and features of NE114. Similarly, at step316, NE111determines whether the information and capabilities sent in the OPEN message309from NE114matches, or is compatible with, the capabilities and features of NE111.

In response to the features and capabilities of both NEs111and NE114being compatible, NEs111and114establish a cBGP session between NEs111and114. In contrast, when the features and capabilities of both NEs111and114are not compatible, a cBGP session cannot be established between NEs111and114.

After establishing a cBGP session between NEs111and114, 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.

InFIG.3, at step319, NE111transmits instructions320to NE114. For example, the instructions320may be a UPDATE message with a Control Information Attribute containing an Assign Adjacency Segment Identifier (SID) to Link Instruction sub-TLV, which instructs NE114to assign an adjacency SID to a link. The adjacency SID and the link are represented in the sub-TLVs shown below with reference toFIGS.10B and10E. An example of an instruction320indicating that the NE114should assign an adjacency SID to a link is represented in the sub-TLV referenced below inFIG.11A.

In response to receiving the UPDATE message, NE114transmits a response or status323back to NE111, as step322. For example, the response or status323indicates the status or result of the execution of the instruction included in the UPDATE message. In one embodiment, the response or status323is 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 status323indicating whether the instruction320was successfully performed is represented in the sub-TLV referenced below inFIG.12.

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 system100or the network. For example, routing information may include labels, addresses, or identifiers of certain NEs along a path to a destination.

In one embodiment, NE111does not receive messages with routing information from NE114and does not send messages with routing information265to NE114because NEs111and114participate in a cBGP session. For example, NE111, acting as the RR and controller, does not send a message with routing information265to NE114after receiving the message from NE112, which has an iBGP session with NE111.

For example, inFIG.3, NE111has already established an iBGP session with NE112, through which messages containing routing information265are permitted to be transmitted. At step326, NE112transmits an UPDATE message containing routing information265to NE111, and NE111receives the UPDATE message. In BGP, NE111is configured to distribute this UPDATE message to connected BGP peers, such as NE114. However, since NE111has established a cBGP session with NE114, NE111is prohibited from forwarding the UPDATE message containing routing information265to NE114. That is, NE111does not send the UPDATE message containing the routing information265to NE114.

In a similar fashion, routing information265learned by NE114is prohibited from being distributed or forwarded to NE111, with which a cBGP session has been established. In some embodiments, when a NE111or114receives routing information265, NEs111and114are prohibited from forwarding or distributing the routing information265to any other cBGP peers.

In some embodiments, iBGP peers and eBGP peers are prohibited from transmitting UPDATE messages to NEs114, or any other NEs with which a cBGP session has been established. In the case that NE114receives an UPDATE message, NEs114is configured to discard, drop, or ignore the UPDATE message. Accordingly, the cBGP session established between NEs111and114prevent unnecessary traffic from being forwarded through the communications system100and clogging network resources.

FIG.4is a diagram illustrating a communications system400configured to implement cBGP according to various embodiments of the disclosure. Communications system400ofFIG.4is similar to communications system100ofFIG.1, except that the communications system400ofFIG.4shows the different BGP session404-411established between NE111and NEs109-110and112-115. In addition, the communications system400ofFIG.4shows that different types of BGP sessions may be established between a single pair of NEs.

Similar to the communications system100ofFIG.1, in the communications system400ofFIG.4, NE111is implemented as the controller and the RR of the communications system400. In this way, NE111has established different types of BGP sessions or connections with the other NEs109-110and112-115in the communications system400. In particular, NE111, positioned within AS106, has established separate eBGP sessions with both NEs109and110, both of which are positioned within AS103. As shown inFIG.4, NE111has established an eBGP session404with NE109and an eBGP session405with NE110.

NE111has also established separate iBGP sessions with NEs112,113,114, and115, all of which are positioned within the same AS106. As shown inFIG.4, NE111has established an iBGP session406with NE112, an iBGP session407with NE113, an iBGP session408with NE114, and an iBGP session409with NE115.

In some embodiments, NE111is configured to establish cBGP sessions with some of the NEs110and112with which other BGP session types have already been established. As shown byFIG.4, NE111has already established an eBGP session405with NE110and an iBGP session406with NE112. In an embodiment, NE111is configured to additionally establish a cBGP session with NEs110and112. In particular, NE111is configured to establish a cBGP session410with NE110and a cBGP session411with NE112.

NE111additionally establishes the cBGP sessions410and411in two different manners. In the first manner, NE111establishes the cBGP sessions410and411separately from the existing BGP sessions. For example, NE111establishes cBGP session410with NE110separately, for example, as a separate tunnel, from the existing eBGP session405. In this example, different types of messages are communicated between NEs111and110through the different types of BGP sessions (e.g., eBGP session405and cBGP session410). In an embodiment, a first type of message is permitted to be communicated through the cBGP session410, in which the first type of message is a control message excluding routing information265. In this embodiment, a second type of message including routing information265should be communicated through the eBGP session405.

For example, when NE111receives an UPDATE message from another BGP peer, NE111may 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 information265, NE111determines that the UPDATE message should be forwarded to NE110through the eBGP session405, not the cBGP session410. In this case, NE111transmits the UPDATE message to NE110through the eBGP session405.

In contrast, when NE111sends an instruction to the NE110, NE111first determines a type of message of the instruction. In response to determining that the instruction is a control message that does not contain routing information265, NE111determines that the instruction should be forwarded to NE110through the cBGP session410. In this case, NE111transmits the instruction to NE110through the cBGP session410.

Similar methodologies are utilized when NE111establishes a cBGP session411with an NE112separately from the existing iBGP session406. For example, NE111establishes a cBGP session411with NE112separately, for example, as a separate tunnel, from the existing iBGP session406. In this example, different types of messages are communicated between NEs111and112through the different types of BGP sessions (e.g., iBGP session406and cBGP session411). In an embodiment, a first type of message is permitted to be communicated through the cBGP session411, in which the first type of message is a control message excluding routing information265. In this embodiment, a message including routing information265should be communicated through the iBGP session406.

In a second manner of establishing a cBGP session, NE111establishes the cBGP sessions410and411by combining the cBGP sessions410and411with the existing eBGP session405and iBGP session406. For example, instead of creating a separate tunnel for the new cBGP session410, NE111creates a combined BGP session with NE110by adding the cBGP session410to the existing eBGP session405. In this example, different types of messages are permitted to be communicated between NEs111and110through 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 information265. In this embodiment, a second type of message including routing information265is also permitted to be communicated through the combined BGP session.

Similar methodologies are utilized when NE111establishes a combined BGP session with an NE112with which an iBGP session406has already been established. For example, NE111establishes a combined BGP session with NE112by, for example, adding a cBGP session411to the existing iBGP session406. In this example, different types of messages are permitted to be communicated between NEs111and112through 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.5is a diagram illustrating a capabilities TLV500sent by an NE in the communications system100ofFIG.1or the communications system400ofFIG.4according to various embodiments of the disclosure. In an embodiment, the capabilities TLV500includes information indicating whether an NE109-115is capable of establishing a cBGP session with another NE109-115. In an embodiment, the capabilities TLV500is included as an optional parameter in an OPEN message, similar to the OPEN messages306and309ofFIG.3. In another embodiment, the capabilities TLV500is a new and separate message transmitted between NEs109-115in a communications system100to indicate a respective capability of the NE109-115.

In the embodiment shown inFIG.5, the capabilities TLV500includes a capability code503, a capability length506, and a capability value509. The capability code503is a one byte field carrying a code indicating whether the NE109-115sending the capabilities TLV500is capable of establishing a cBGP session with another NE109-115. In an embodiment, the code is a value presenting whether the NE109-115is capable of establishing a cBGP session with another NE109-115or whether the NE109-115is not capable of establishing a cBGP session with another NE109-115.

The capability length506is a one byte field indicating that the length of the capability value509is 2 bytes. The capability value509is a 2 byte field carrying various flags. In an embodiment, the capability value509carries a C flag511and an I flag514. In an embodiment, the C flag511is set to indicate whether the NE109-115sending the capabilities TLV500acts as a controller of the communications system100. For example, when the C flag511is set to 1, the C flag511indicates that the NE109-115sending the capabilities TLV500acts as the controller of the communications system100. Similarly, when the C flag511is set to 0, the C flag511indicates that the NE109-115sending the capabilities TLV500does not act as the controller of the communications system100.

In an embodiment, the I flag514is set to indicate whether the NE109-115sending the capabilities TLV500is configured to create a separate cBGP session or a combined BGP session, when applicable, as described above with reference toFIG.4. For example, when the I flag514is set to 1, the NE109-115sending the capabilities TLV500is configured to create a cBGP session with another NE109-115that is separate and independent from any other existing BGP session. For example, the NE109-115sending the capabilities TLV500is configured to create a new cBGP session, by creating a separate tunnel or path, with the other NE109-115. Similarly, when the I flag514is set to 0, the NE109-115sending the capabilities TLV500is configured to create a combined BGP session with another NE109-115.

FIG.6is a diagram illustrating a communications system600configured to implement a cBGP peer session within a peer group according to various embodiments of the disclosure. InFIG.6, the communications system600includes a controller603and two peer groups606and609. The peer groups606and609refer to a set or group of NEs615-617and NEs620-622in the communications system600that share a similar characteristic or policy.

InFIG.6, the peer group606includes NEs615,616, and617, while peer group609includes NEs620,621, and622. Within peer group606, NEs615-617are 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, NEs615-617are associated with the same tenant, and thus, the same tenant identifier, even though NEs615-617may be located in geographically distinct regions. For this reason, NEs615-617are grouped together into a single peer group606.

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

In an embodiment, NEs615-617and NEs620-622are similar to NEs109-115of the communications systems100and400. In another embodiment, the NEs615-617and620-622are 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.

NEs615-617and620-622are each coupled to the controller603via links630-632and633-635, respectively. Links630-632and633-635may be similar to links120-125, in that links630-632and633-635may be wired or wireless links or interfaces interconnecting each of the NEs615-617and620-622to the controller603. Links630-632and633-635are configured to forward traffic according to various routing protocols, such as BGP (e.g., iBGP, eBGP, and cBGP).

In an embodiment, the controller603is similar to NE111, in that the controller may act as the RR of the communications system600. In another embodiment, the controller603may be a separate server or site external to the ASs included in the communications system600.

In some embodiments, the controller603, NEs615-617, and620-622are configured to selectively communicate certain types of information by establishing cBGP sessions between members of the peer groups606and609and the controller603. In an embodiment, the controller603establishes cBGP session with NEs615-617. The controller603separately establishes a cBGP session with NEs620-622.

After the cBGP session has been established between the controller603and members of the peer groups606and609, the controller603determines whether to forward or distribute information received from other member NEs615-617and620-622within a peer group606and609. In this embodiment, certain types of information may be permitted to be forwarded or distributed to NEs615-617and620-622within the same peer group606and609.

For example, information that may be shared within member NEs615-617and620-622of a peer group606and609include private addresses of NEs615-617and620-622within the same peer group606and609, port addresses for ports of particular NEs615-617and620-622within the same peer group606and609, security related information for NEs615-617and620-622within the same peer group606and609, information describing Ethernet virtual private networks (EVPNs) for NEs615-617and620-622within the same peer group606and609, information describing intelligent virtual private networks (IVPNs) for NEs615-617and620-622within the same peer group606and609, etc. For example, when the communications system600is a software defined wide area network (SD-WAN), information that may be shared within member NEs615-617and620-622of a peer group606and609includes 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 NEs615-617and620-622of a peer group606and609. In one embodiment, routing information265may also be shared between member NEs615-617and620-622of the same peer group606and609.

In an embodiment, a network administrator or operator preconfigures the controller603to include identifiers, labels, or addresses of each of the NEs615-617and620-622within a particular peer group606and609. In another embodiment, the controller603determines member NEs615-617and620-622of the peer group606and609intelligently based on characteristics or properties associated with the NEs615-617and620-622. For example, the controller603may obtain the tenant identifiers for each NE615-617and then create the peer group606based on the matching tenant identifiers for NEs615-617.

In an embodiment, the controller603distributes information based on peer group policies275defined by the network administrator or operator specifying the types of information that may be shared within member NEs615-617and620-622of the peer group606or609. In another embodiment, the controller603may be configured to intelligently determine peer group policies275defining the types of information that may be securely shared between member NEs615-617and620-622of a peer group606or609.

FIG.7is a message sequence diagram illustrating a method700of implementing cBGP in the communications system600ofFIG.6according to various embodiments of the disclosure. Method700is implemented by NEs in the communications system600, such as the controller603and NEs615,616,620, and621. Method700is performed after the controller603has established a cBGP session with NEs615,616,620, and621and after the peer groups606and609are established. As described above, the peer group606includes NEs615and616, while the peer group609includes NEs620and621.

The controller603may obtain peer data780A and780B, either by generating the peer data780A and780B or receiving the peer data780A and780B from another BGP peer/NE. For example, the peer data780A includes an address of the NE617from the peer group606(seeFIG.6), and the peer data780B may include port information regarding NE622from peer group609(seeFIG.6).

Prior to transmitting the peer data780A-B to other member NEs of the respective peer groups606and609, the controller603determines whether the peer data780A-B comprises a type of data that is permitted to be distributed or forwarded to other member NEs of the respective peer groups606and609based on a peer group policy275defined for each of the peer groups606and609. In an embodiment, the peer group policies275indicate the type of data that may be shared between a respective peer group606and609. In this embodiment, the controller603compares the peer data780A-B with the respective peer group policy275for each peer group606and609to determine whether the peer data780A-B is permitted to be shared.

When the peer group policy275for the peer group606indicates that address information is permitted to be shared with other NEs in the peer group606, at step703, the controller603transmits the peer data780A to NE616of peer group606. Notably, the controller603did not forward the peer data780A to NEs620or621, which are members of a different peer group609. Similarly, when peer group policy275for the peer group609indicates that port information is permitted to be shared with other NEs in the peer group609, at step706, the controller603transmits the peer data780B to NE620of peer group609. Notably, the controller603did not forward the peer data780B to NEs615or616, which are members of a different peer group606. In an embodiment, the NEs within the peer groups606and609also locally store the peer group policies275that are used to determine whether to share the peer data780A-B.

FIGS.8A-Care diagrams illustrating an UPDATE message800encoded based on BGP4according to various embodiments of the disclosure. The UPDATE message800may be encoded similar to the UPDATE message described in the Network Working Group (NWG) Request for Comments (RFC) 4271 document, entitled “A Border Gateway Protocol 4 (BGP-4),” by Y. Rekhter, Ed., et. al., dated January 2006. As shown byFIG.8, the UPDATE message800includes a header802and various attributes810.

In an embodiment, the UPDATE message800may be transmitted by NE111, for example, at step319ofFIG.3, or transmitted by the NE114, for example, at step322. With references toFIGS.8-12, the term “node” may be used interchangeably with “NE.”

The header802includes a marker803, a length806, and a type809. The marker803is a 16-octet field included for compatibility and may be set to all ones. The length806is a 2-octet unsigned integer indicating the total length of the UPDATE message800, including the header802, in octets. The type809is a 1-octet unsigned integer indicating a type code of the UPDATE message800carrying the attributes810, and in particular, the control information830. In an embodiment, the type code is 2, which is the existing type code of the existing UPDATE message. When the UPDATE message is transmitted over a cBGP session, it contains control information830. In another embodiment, the type code is a new number other than 2. This new number (i.e., new type code) indicates that the message is a UPDATE message containing control information830.

The attributes810include details used to advertise feasible routes that share common path attributes to a peer, or to withdraw multiple unfeasible routes from service. As shown byFIG.8, the attributes810include at least one of a withdrawn routes length812, withdrawn routes815, total path attribute length818, path attributes821, NLRIs824, or control information830. The withdrawn routes length812is a 2-octet unsigned integer indicating the total length of the withdrawn routes815in octets. The withdrawn routes815is 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 2-tuple of the form <length, prefix>.

FIG.8Bshows the 2-tuple form used to signal each IP address prefix in the withdrawn routes815. The 2-tuple includes a length8531-octet field indicating the length in bits of the IP address prefix856field. The IP address prefix856field carries the IP address prefix.

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

FIG.8Cshows the 2-tuple form used to signal each IP address prefix in the NLRIs824. The 2-tuple includes a length8631-octet field indicating the length in bits of the IP address prefix866field. The IP address prefix863field carries the IP address prefix.

According to some embodiments, the attributes810includes the control information830. In an embodiment, the instructions320and the response or status323described above with reference toFIG.3is carried in the control information830of the UPDATE message800. In this embodiment, NEs or nodes that have established cBGP sessions with one another are only permitted to transmit UPDATE messages800carrying instructions320and/or the response or status323in the control information830.

FIG.9is a diagram illustrating the control information830included in the update message800according to various embodiments of the disclosure. The control information attribute830includes various fields, such as attribute flags903, attribute type906, length909, identifier912, and one or more sub-TLVs915. The attribute flags903include 8 bits, in which each one is a flag representing information regarding the control information830. In an embodiment, bit0is an optional bit indicating whether the control information830is optional or well-known. For example, bit0is set to 1 if the control information830is optional or set to 0 if the control information830is well-known. Bit1may be a transitive bit indicating whether the control information830is transitive or non-transitive. For example, bit1is set to 1 if the control information830is transitive or set to 0 if the control information830is non-transitive. Bit2may be a partial bit indicating whether the control information830is partial or complete. For example, bit2is set to 1 if the control information830is partial or set to 0 if the control information830is complete. Bit3is an extended length bit indicating whether the length909field of the control information830is 1 or 2 octets. For example, bit3is set to 0 if the length909of control information830is 1 octet or set to 1 if the length909of the control information830is 2 octets. In an embodiment, for the control information830, bit0is set to 1 since the control information830is optional, and bit1is set to 0 since the control information830is non-transitive.

The attribute type906includes a code or value indicating that the attribute is the control information830. The length909is an 8 bit or 16 bit value indicating the number of bytes in the control information830. The identifier912is a 32 bit field identifying a set of instructions in the control information830. The sub-TLVs915include one or more sub-TLVs915carrying information, instructions320, or status323, as will be further described in the examples below.

FIGS.10A-Eare diagrams illustrating examples of sub-TLVs915A-E included in the control information attribute830according to various embodiments of the disclosure. The sub-TLVs915A-E shown inFIGS.10A-Ecarry information regarding nodes/NEs, links, or interfaces upon with the instructions320are to be performed.

FIG.10Ashows a node sub-TLV915A indicating a node/NE receiving the instructions320. The node sub-TLV915A includes various fields, such as, the node type1003, length1006, and node IP address1009. The node type1003carries a value indicating that the sub-TLV915A is the node sub-TLV915A. The length1006indicates either 4 bytes or 16 bytes, based on whether the node IP address1009caries an IPv4 address or an IPv6 address. When the node IP address1009carries an IPv4 address, the length1006indicates 4 bytes. When the node IP address1009carries an IPv6 address, the length1006indicates 16 bytes. The node IP address1009caries the IP address (either IPv4 address or IPv6 address) of the node/NE receiving the instructions320.

FIG.10Bshows a link sub-TLV915B indicating a link to which the instructions320are applied. The link sub-TLV915B includes various fields, such as, the link type1011, the length1012, link local IP address1013, and link remote IP address1014. The link type1011carries a value indicating that the sub-TLV915B is the link sub-TLV915B. The length1006indicates either 8 bytes or 32 bytes, depending on whether the IP addresses included in the link local IP address1013and the link remote IP address1014are IPv4 addresses (4 bytes) or IPv6 address (16 bytes). The link local IP address1013carries the local IP address of the link as either an IPv4 address or an IPv6 address. The link remote IP address1014carries the remote IP address of the link as either an IPv4 address or an IPv6 address.

As shown byFIG.10C, the IPv4 prefix sub-TLV915C includes various fields, such as the IPv4 prefix type1021, length1022, prefix length1023, and IPv4 prefix1024. The IPv4 prefix type1021carries a value indicating that the sub-TLV915C is the IPv4 prefix sub-TLV915C. The length1022carries the length of the IPv4 prefix sub-TLV915C excluding the type field1021and length1022field, which may be a variable length. The prefix length1023carries a length of the IPv4 prefix1024, and the IPv4 prefix1024carries the IPv4 prefix.

As shown byFIG.10D, the IPv6 prefix sub-TLV915D includes various fields, such as the IPv6 prefix type1031, length1032, prefix length1033, and IPv6 prefix1034. The IPv6 prefix type1031carries a value indicating that the sub-TLV915D is the IPv6 prefix sub-TLV915D. The length1032carries the length of the IPv6 prefix sub-TLV915D excluding the type field1031and length1032field, which may be a variable length. The prefix length1033carries a length of the IPv6 prefix1034, and the IPv6 prefix1034carries the IPv6 prefix.

FIG.10Eshows an adjacency segment identifier (SID) sub-TLV915E indicating an adjacency SID to which the instructions320are to be applied. The adjacency SID sub-TLV915E includes various fields, such as, the adjacency SID type1041, length1042, flags1043, weight1044, reserved bits, and an SID, label, or index1045. The adjacency SID type1041includes a value indicating that the sub-TLV915E is the adjacency SID sub-TLV915E. The length1042carries a length of the adjacency SID sub-TLV915E excluding the type field1041and length1042field. The flags1043carry 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 weight1044is used for load balancing purposes. The SID, label, or index1045carries a 4 octet index defining an offset in the SID/label space, a 3 octet local label, or an SID. Additional details regarding the SID sub-TLV915E is further described in the Open Shortest Path First IGP Draft Document, entitled “OSPF Extensions for Segment Routing,” by P. Psenak, et. al., dated Dec. 3, 2018.

FIGS.10A-Eshow sub-TLVs915A-E carrying information regarding nodes/NEs, links, or interfaces upon with the instructions320are to be performed.FIGS.10A-Eonly shows a few examples of such sub-TLVs915that can be carried in the control information830of the UPDATE message800. It should be appreciated that other sub-TLVs915carrying other types of information may otherwise be included in the control information830of the UPDATE message800.

FIGS.11A-Bare diagrams illustrating sub-TLVs915F-G including instructions320carried in the control information830according to various embodiments of the disclosure. The instructions320are 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-TLVs915A-E. In an embodiment, the sub-TLVs915F-G including instructions320are permitted to be communicated during a cBGP session.

FIG.11Ashows an assign adjacency SID to link sub-TLV915F according to various embodiments of the disclosure. The assign adjacency SID to link sub-TLV915F includes an instruction320for a node/NE receiving the UPDATE message800to assign an adjacency SID to a link. The assign adjacency SID to link sub-TLV915F includes various fields, such as, an assign adjacency SID link type1103, a length field1106, the adjacency SID sub-TLV915E, and the link sub-TLV915B. The assign adjacency SID link type1103carries a value indicating that the sub-TLV915F is the assign adjacency SID to link sub-TLV915F. The length1106carries a length of the assign adjacency SID to link sub-TLV915F excluding the type field1103and length1106field. As described above, the adjacency SID sub-TLV915E carries an SID, label, or index1045, and the link sub-TLV915B carries the link local IP address1013and the link remote IP address1014. This information is used by the node/NE receiving the assign adjacency SID to link sub-TLV915F to assign an adjacency SID, identified in the assign adjacency SID to link sub-TLV915F, to a link, which is also identified in the assign adjacency SID to link sub-TLV915F.

FIG.11Bshows flow redirect sub-TLV915G according to various embodiments of the disclosure. The flow redirect sub-TLV915G includes an instruction320for a node receiving the UPDATE message800to redirect a data flow. The flow redirect sub-TLV915G includes various fields, such as, a flow redirect type1153, a length field1156, an indirection ID1159, and a flow specification1161. The flow redirect type1153carries a value indicating that the sub-TLV915G is the flow redirect sub-TLV915G. The length1106carries a length of the flow redirect sub-TLV915G excluding the type field1153and length1156field. The indirection ID1159identifies a tunnel by which traffic should be redirected. In one embodiment, the indirection ID1159is 32 bits. The flow specification1161describes the traffic that should be redirected through the tunnel identified by the indirection ID1159. In one embodiment, the flow specification1161is a link sub-TLV915B, which indicates that the flow is the traffic from the link given by the link sub-TLV. In another embodiment, the flow specification1161is an IPv4 prefix sub-TLV915C, which describes a traffic flow. This information is used by the node/NE receiving the flow redirect sub-TLV915G to redirect the traffic described by the flow specification1161to the tunnel identified in the indirection ID1159.

FIG.12is a diagram illustrating a status sub-TLV915H including a response or status323carried in the control information830according to various embodiments of the disclosure. The status sub-TLV915H is populated in a new UPDATE message800carrying information indicating whether the node receiving the first UPDATE message800successfully performed the instruction320carried in the first UPDATE message800. The status sub-TLV915H includes various fields, such as the status type1203, the length1206, reserved bits, status brief (SB)1212, error code1215, and a reason if failure occurs1217. The status type1203carries a value indicating that the sub-TLV915H is the status sub-TLV915H. The length1206carries a length of the status sub-TLV915H excluding the type field1203and length1206field. The SB1212includes a value indicating whether the instructions320were successfully performed. For example, SB1212may be set to 1 if the instructions320were successfully performed, 2 if the instructions320were not successfully performed or failed, and 3 if the instructions320were only partially performed. The error code1215may carry an error code or value when the instruction320was unable to be successfully performed identifying a pre-determined reason as to why the instruction320instruction320was unable to be successfully performed. The reason if failure occurs1217is an optional field that may carry additional information describing reasons why the instruction320was unable to be successfully performed.

In an embodiment, during a cBGP session, when a node/NE receives a first UPDATE message800containing control information830, in which the control information830carries an instruction320, the node/NE may first attempt to perform the instruction320. For example, the control information830may include the assign adjacency SID to link sub-TLV915F. The node/NE may attempt to assign an adjacency SID, identified in the assign adjacency SID to link sub-TLV915F, to a link, which is also identified in the assign adjacency SID to link sub-TLV915F. The node may then populate a new (or second) UPDATE message800with control information830including a status sub-TLV915H indicating whether the adjacency was properly assigned and the identifier912which is from the control information830in the first UPDATE message800. In this manner, the cBGP session permits UPDATE messages800carrying control information830to be communicated amongst NEs or nodes that have established a cBGP session. In one embodiment, only UPDATE messages800carrying the control information830, and no other attributes810, are permitted to communicated amongst NEs or nodes that have established a cBGP session. In another embodiment, only UPDATE messages800carrying the control information830are permitted to communicated amongst NEs or nodes that have established a cBGP session, regardless of whether the UPDATE message800includes other attributes810.

FIG.13is a flowchart illustrating a method1300of establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. Method1300may be implemented by a controller, such as NE111, NE200, or603of the communications systems100,400, or600. Method1300may be implemented after the controller has established a TCP three-way handshake with another NE, such as NE114.

At step1303, the controller establishes a cBGP peer session with NE114. For example, NE111establishes a cBGP peer session with NE114by sending an OPEN message indicating that NE111is capable of establishing a cBGP peer session. NE111then receives an OPEN message from NE114indicating that NE114is capable of establishing a cBGP peer session. As described with reference toFIG.3, when both NE111and NE114are capable of establishing a cBGP peer session, the cBGP peer session is established between NE111and NE114. 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 information265, such as instructions, responses to the instructions, and status messages. In this embodiment, messages containing routing information265are prohibited from being communicated through the cBGP session.

At step1306, NE111transmits a message to NE114through the cBGP peer session. For example, Tx/Rx210of NE111transmits a message to NE114through the cBGP peer session. For example, the message is an instruction regarding an interface of NE114and does not contain routing information265.

At step1309, NE111determines whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information265. For example, the cBGP module224is executed by the processor230to determine whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information265.

At step1311, NE111transmits the message to the NE through the cBGP session if the message is permitted to be communicated through the cBGP session. For example, Tx/Rx210of NE111transmits the message to NE114if the message is permitted to be communicated through the cBGP session (i.e., if the message does not contain routing information265).

At step1315, NE111receives a response message from the NE through the cBGP session. For example, Tx/Rx210of NE111receives a response message from NE114through the cBGP peer session. For example, the response message indicates whether or not NE114has successfully assigned the segment identifier (SID) to the interface identified in the message sent at step1306.

FIG.14is a flowchart illustrating another method1400of establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. Method1400may be implemented by an NE in the communications system100that is not the controller, such as NEs109-110or112-115. Method1400may be implemented after the NE, such as NE109, has established a TCP three-way handshake with the controller, such as NE111.

At step1403, the NE109establishes a cBGP peer session with NE111. For example, NE109establishes a cBGP peer session with NE111by sending an OPEN message indicating that NE109is capable of establishing a cBGP peer session. NE109then receives an OPEN message from NE111indicating that NE111is capable of establishing a cBGP peer session. As described with reference toFIG.3, when both NE111and NE109are capable of establishing a cBGP peer session, the cBGP peer session is established between NE111and NE109. 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 information265, such as instructions, responses to the instructions, and status messages. In this embodiment, messages containing routing information265are prohibited from being communicated through the cBGP session.

At step1406, NE109receives a message from NE111through the cBGP peer session. For example, Tx/Rx210of NE109receives a message from NE111through the cBGP peer session. For example, the message of the first type is an instruction regarding an interface of NE109and does not contain routing information265.

At step1409, NE109determines whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information265. For example, the cBGP module224is executed by the processor230to determine whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information265.

At step1412, NE109transmits a response message to NE111through the cBGP peer session. For example, Tx/Rx210of NE109transmits a response message to NE111through the cBGP peer session. For example, the response message indicates whether or not NE109has successfully assigned the segment identifier (SID) to the interface identified in the message sent at step1406.

FIG.15is a diagram illustrating an apparatus1500for establishing a cBGP session and communicating data through a cBGP session according to various embodiments of the disclosure. The apparatus1500comprises a means for establishing1503, a means for transmitting1506, a means for determining1508, and a means for receiving1509.

In an embodiment in which the apparatus1500is implemented as a controller, the means for establishing1503comprises a means for establishing a cBGP peer session with another NE in the communications system, such as communications system100or400. For example, NE111establishes a cBGP peer session with NE114by sending an OPEN message indicating that NE111is capable of establishing a cBGP peer session and receiving an OPEN message from NE114indicating that NE114is capable of establishing a cBGP peer session. As described with reference toFIG.3, when both NE111and NE114are capable of establishing a cBGP peer session, the cBGP peer session is established between NE111and NE114. In an embodiment, the means for receiving1509comprises a means for receiving a message for communication through the cBGP session to an NE114. In this embodiment, the means for determining1508comprises a means for determining whether the message is permitted to be communicated through the cBGP session based on whether the message carries routing information265. In this embodiment, the means for transmitting1506comprises a means for transmitting the message to the other NE in the communications system through the cBGP session. In this embodiment, the means for receiving1509comprises 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 apparatus1500is implemented as an NE in the network excluding the controller, the means for establishing1503comprises establishing a cBGP peer session with the controller of the communications system. For example, NE109establishes a cBGP peer session with NE111by sending an OPEN message indicating that NE109is capable of establishing a cBGP peer session and receiving an OPEN message from NE111indicating that NE111is capable of establishing a cBGP peer session. As described with reference toFIG.3, when both NE111and NE109are capable of establishing a cBGP peer session, the cBGP peer session is established between NE111and NE109. The means for receiving1509comprises receiving a message from the controller through the cBGP session. The means for determining1508comprises a means for determining whether the message is permitted to be communicated through the cBGP session. The means for transmitting1506comprises 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 spirit or 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 information265. In this embodiment, a second type of message including routing information265is also permitted to be communicated through the combined BGP session.