U.S. patent application number 12/957050 was filed with the patent office on 2011-03-24 for withdrawing multiple advertised routes based on a single tag which may be of particular use in border gateway protocol.
This patent application is currently assigned to Cisco Technology, Inc., a corporation of California. Invention is credited to John Galen Scudder, David Delano Ward.
Application Number | 20110069639 12/957050 |
Document ID | / |
Family ID | 43357390 |
Filed Date | 2011-03-24 |
United States Patent
Application |
20110069639 |
Kind Code |
A1 |
Scudder; John Galen ; et
al. |
March 24, 2011 |
Withdrawing Multiple Advertised Routes Based On A Single Tag Which
May Be Of Particular Use In Border Gateway Protocol
Abstract
Advertised routes are associated with a particular tag in a
routing database in a second router. A first router subsequently
sends one or more messages associated with a route withdraw
operation that specifies the particular tag, such that second
router can identify, based on the particular tag, a set including
multiple routes, and remove those multiple routes from its routing
database. For example, the tag may be a Border Gateway Protocol
attribute, a Border Gateway Protocol communities attribute, or some
other indication, numeric quantity, or opaque value.
Inventors: |
Scudder; John Galen; (Ann
Arbor, MI) ; Ward; David Delano; (Somerset,
WI) |
Assignee: |
Cisco Technology, Inc., a
corporation of California
San Jose
CA
|
Family ID: |
43357390 |
Appl. No.: |
12/957050 |
Filed: |
November 30, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10739238 |
Dec 18, 2003 |
7860115 |
|
|
12957050 |
|
|
|
|
Current U.S.
Class: |
370/254 |
Current CPC
Class: |
H04L 45/00 20130101;
H04L 45/026 20130101; H04L 45/02 20130101; H04L 45/46 20130101;
H04L 45/04 20130101 |
Class at
Publication: |
370/254 |
International
Class: |
H04L 12/28 20060101
H04L012/28 |
Claims
1. A method performed by a first router for requesting routes to be
withdrawn from a second router, the method comprising: sending, by
the first router one or more routing protocol messages, for
identifying to the second router a plurality of particular routes
and a particular tag associated with the plurality of particular
routes for the second router to associate each route of the
plurality of particular routes with the particular tag in a manner
that all of the routes in the plurality of particular routes in a
routing database can be subsequently identified by the second
router based on the particular tag; and sending, by the first
router subsequent to said operation of sending of one or more
routing protocol messages, a particular routing protocol message
associated with a route withdraw operation for identifying to the
second router to withdraw from the routing database one or more
routes based on a specified tag, with the particular routing
protocol message including the particular tag as the specified tag
for use by the second router in identifying and withdrawing the
plurality of particular routes from the routing database.
2. The method of claim 1, wherein the particular tag is an opaque
value selected by the first router.
3. The method of claim 1, wherein said one or more routing protocol
messages are Border Gateway Protocol messages, and the particular
tag is a Border Gateway Protocol attribute.
4. The method of claim 1, wherein said one or more routing protocol
messages are Border Gateway Protocol messages, and the particular
tag is Border Gateway Protocol communities attribute.
5. The method of claim 1, wherein the specified tag is an opaque
value selected by a particular router, advertising the plurality of
particular routes; wherein the particular router is different than
the first and second routers.
6. A first router comprising one or more processors and memory,
wherein the memory stores one or more instructions that, when
executed by said one or more processors, perform operations
comprising: sending, by the first router one or more routing
protocol messages, for identifying to the second router a plurality
of particular routes and a particular tag associated with the
plurality of particular routes for the second router to associate
each route of the plurality of particular routes with the
particular tag in a manner that all of the routes in the plurality
of particular routes in a routing database can be subsequently
identified by the second router based on the particular tag; and
sending, by the first router subsequent to said operation of
sending of one or more routing protocol messages, a particular
routing protocol message associated with a route withdraw operation
for identifying to the second router to withdraw from the routing
database one or more routes based on a specified tag, with the
particular routing protocol message including the particular tag as
the specified tag for use by the second router in identifying and
withdrawing the plurality of particular routes from the routing
database.
7. The first router of claim 6, wherein the particular tag is an
opaque value selected by the first router.
8. The first router of claim 6, wherein said one or more routing
protocol messages are Border Gateway Protocol messages, and the
particular tag is a Border Gateway Protocol attribute.
9. The first router of claim 6, wherein said one or more routing
protocol messages are Border Gateway Protocol messages, and the
particular tag is Border Gateway Protocol communities
attribute.
10. The first router of claim 6, wherein the specified tag is an
opaque value selected by a particular router, advertising the
plurality of particular routes; wherein the particular router is
different than the first and second routers.
11. A first router comprising: means for sending, by the first
router one or more routing protocol messages, for identifying to
the second router a plurality of particular routes and a particular
tag associated with the plurality of particular routes for the
second router to associate each route of the plurality of
particular routes with the particular tag in a manner that all of
the routes in the plurality of particular routes in a routing
database can be subsequently identified by the second router based
on the particular tag; and means for sending, by the first router
subsequent to said operation of sending of one or more routing
protocol messages, a particular routing protocol message associated
with a route withdraw operation for identifying to the second
router to withdraw from the routing database one or more routes
based on a specified tag, with the particular routing protocol
message including the particular tag as the specified tag for use
by the second router in identifying and withdrawing the plurality
of particular routes from the routing database.
12. The first router of claim 11, wherein the particular tag is an
opaque value selected by the first router.
13. The first router of claim 11, wherein said one or more routing
protocol messages are Border Gateway Protocol messages, and the
particular tag is a Border Gateway Protocol attribute.
14. The first router of claim 11, wherein said one or more routing
protocol messages are Border Gateway Protocol messages, and the
particular tag is Border Gateway Protocol communities
attribute.
15. The first router of claim 11, wherein the specified tag is an
opaque value selected by a particular router, advertising the
plurality of particular routes; wherein the particular router is
different than the first and second routers.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This is a continuation of copending nonprovisional
application Ser. No. 10/739,238, filed Dec. 18, 2003, which is
hereby incorporated by reference in its entirety.
TECHNICAL FIELD
[0002] One embodiment of the invention relates to communications
and computer systems, especially networked routers, packet
switching systems, and other devices; and more particularly, one
embodiment relates to withdrawing multiple advertised routes based
on a single tag which may be of particular use in Border Gateway
Protocol.
BACKGROUND
[0003] The communications industry is rapidly changing to adjust to
emerging technologies and ever increasing customer demand. This
customer demand for new applications and increased performance of
existing applications is driving communications network and system
providers to employ networks and systems having greater speed and
capacity (e.g., greater bandwidth). In trying to achieve these
goals, a common approach taken by many communications providers is
to use packet switching technology. Increasingly, public and
private communications networks are being built and expanded using
various packet technologies, such as Internet Protocol (IP). Note,
nothing described or referenced in this document is admitted as
prior art to this application unless explicitly so stated.
[0004] A network device, such as a switch or router, typically
receives, processes, and shares routing information among other
nodes of a network. Border Gateway Protocol (BGP) is a common
protocol used to exchange routing information between subnetworks
within the network. BGP is an inter-Autonomous System routing
protocol. One version of it is described in A BORDER GATEWAY
PROTOCOL 4 (BGP-4), RFC 1771, IETF, March 1995, which is hereby
incorporated by reference. Another version is described in A BORDER
GATEWAY PROTOCOL 4 (BGP-4), draft-ietf-idr-bgp4-22, IETF working
draft, October 2003, which is hereby incorporated by reference.
Some other documents which describe aspects of Border Gateway
Protocol include: BGP COMMUNITIES ATTRIBUTE, RFC 1997, IETF, August
1996; CAPABILITIES ADVERTISEMENT WITH BGP-4, RFC 3392, IETF,
November 2002; and BGP Extended Communities Attribute,
draft-ietf-idr-bgp-ext-communities-06, IETF working draft, August
2003; with all of these documents being hereby incorporated by
reference.
[0005] A primary function of a BGP speaking system is to exchange
network reachability information with other BGP systems. This
network reachability information includes information on the list
of Autonomous Systems (aSs) that reachability information
traverses. This information is sufficient to construct a graph of
AS connectivity from which routing loops may be pruned and some
policy decisions at the AS level may be enforced. To characterize
the set of policy decisions that can be enforced using BGP, one
must focus on the rule that a BGP speaker advertise to its peers
(other BGP speakers which it communicates with) in neighboring ASs
only those routes that it itself uses. Note, an Autonomous System
typically refers to a set of routers under a single technical
administration, using an interior gateway protocol and common
metrics to route packets within the AS, and using an exterior
gateway protocol to route packets to other ASs. It has also become
common for a single AS to use several interior gateway protocols
and sometimes several sets of metrics within an AS.
[0006] Communicating nodes initially exchange their entire BGP
routing table, and then send incremental updates as the routing
tables change. BGP does not require periodic refresh of the entire
BGP routing table. Therefore, a BGP speaker must retain the current
version of the entire BGP routing tables of all of its peers for
the duration of the connection. KeepAlive messages are sent
periodically to ensure the liveness of the connection. Notification
messages are sent in response to errors or special conditions. If a
connection encounters an error condition, a notification message is
sent, the connection is closed and the routes associated with the
connection are withdrawn from the routing tables.
[0007] A route may be viewed as a unit of information that pairs a
destination with the attributes of a path to that destination. For
example, a route may be considered to be one or more Network Layer
Reachability Information (NLRI), which are associated with one set
of path attributes.
[0008] Routes are advertised between a pair of BGP speakers in
Update messages, with the destination being the systems whose IP
addresses are reported in the Network Layer Reachability
Information (NLRI) field of the Update message, and the path is the
information reported in the path attributes fields of the same
Update message. Routes are stored in the Routing Information Bases
(RIBs): namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out.
Routes that will be advertised to other BGP speakers must be
present in the Adj-RIB-Out; routes that will be used by the local
BGP speaker must be present in the Loc-RIB, and the next hop for
each of these routes must be present in the local BGP speaker's
forwarding information base; and routes that are received from
other BGP speakers are present in the Adj-RIBs-In.
[0009] If a BGP speaker chooses to advertise a route, it may add to
or modify the path attributes of the route before advertising it to
a peer. BGP provides mechanisms by which a BGP speaker can inform
its peer that a previously advertised route is no longer available
for use. There are three methods specified in RFC 1771 by which a
given BGP speaker can indicate that a route has been withdrawn from
service: the IP prefix that expresses destinations for a previously
advertised route can be advertised in the withdrawn routes field in
the Update message, thus marking the associated route as being no
longer available for use; a replacement route with the same Network
Layer Reachability Information can be advertised; and the BGP
speaker to BGP speaker connection can be closed, which implicitly
removes from service all routes which the pair of speakers had
advertised to each other.
[0010] An Update message is used to advertise a single feasible
route to a peer, or to withdraw multiple unfeasible routes from
service. An Update message may simultaneously advertise a feasible
route and withdraw multiple unfeasible routes from service. The
Update message always includes the fixed-size BGP header, and can
optionally include other fields including: Unfeasible Routes
Length, Withdrawn Routes, Total Path Attribute Length, Path
Attributes, and Network Layer Reachability Information.
[0011] The Unfeasible Routes Length field indicates the total
length of the Withdrawn Routes field in octets.
[0012] The Withdrawn Routes field is a variable length field that
contains a list of IP address prefixes for the routes that are
being withdrawn from service. Each IP address prefix is encoded as
a two-tuple of the form <length, prefix>, with the Length
field indicating the length in bits of the IP address prefix, with
a length of zero indicating a prefix that matches all IP addresses
(with prefix, itself, of zero octets); and the Prefix field
containing IP address prefixes followed by enough trailing bits to
make the end of the field fall on an octet boundary. Note that the
value of trailing bits is irrelevant.
[0013] The Total Path Attribute Length includes an unsigned integer
indicating the total length of the Path Attributes field in octets.
Its value must allow the length of the Network Layer Reachability
field to be determined as specified below. A value of 0 indicates
that no Network Layer Reachability Information field is present in
this Update message.
[0014] The Path Attributes is a variable length sequence of path
attributes and is present in every Update. Each path attribute is a
triple <attribute type, attribute length, attribute value> of
variable length.
[0015] The Network Layer Reachability Information field is a
variable length field containing a list of IP address prefixes.
[0016] An Update message can advertise at most one route, which may
be described by several path attributes. All path attributes
contained in a given Update messages apply to the destinations
carried in the Network Layer Reachability Information field of the
Update message.
[0017] An Update message can list multiple routes to be withdrawn
from service. Each such route is identified by its destination
(expressed as an IP prefix), which unambiguously identifies the
route in the context of the BGP speaker-BGP speaker connection to
which it has been previously been advertised. An Update message may
advertise only routes to be withdrawn from service, in which case
it will not include path attributes or Network Layer Reachability
Information. Conversely, it may advertise only a feasible route, in
which case the Withdrawn Routes field need not be present.
[0018] If the Update message contains a non-empty Withdrawn Routes
field, the previously advertised routes whose destinations
(expressed as IP prefixes) are contained in this field shall be
removed from the Adj-RIB-In. This BGP speaker shall run its
Decision Process since the previously advertised route is no longer
available for use.
SUMMARY
[0019] Disclosed are, inter alia, methods, apparatus, data
structures, computer-readable medium, mechanisms, and means for
withdrawing routes based on a tag. One embodiment includes: a
method performed by a first router for requesting routes to be
withdrawn from a second router; or possibly, an apparatus such as
the first router itself. One embodiment is configured to send one
or more routing protocol messages for identifying to the second
router a plurality of particular routes and a particular tag
associated with the plurality of particular routes for the second
router to associate each route of the plurality of particular
routes with the particular tag in a manner that all of the routes
in the plurality of particular routes in a routing database can be
subsequently identified by the second router based on the
particular tag. Additionally, the first router is configured to
send, subsequent to said operation of sending of one or more
routing protocol messages, a particular routing protocol message
associated with a route withdraw operation for the second router to
withdraw from the routing database one or more routes based on a
specified tag, with the particular routing protocol message
including the particular tag as the specified tag for use by the
second router in identifying and withdrawing the plurality of
particular routes from the routing database.
[0020] In one embodiment, the particular tag is an opaque value
selected by the first router. In one embodiment, said one or more
routing protocol messages are Border Gateway Protocol messages, and
the particular tag is a Border Gateway Protocol attribute. In one
embodiment, said one or more routing protocol messages are Border
Gateway Protocol messages, and the particular tag is Border Gateway
Protocol communities attribute. In one embodiment, the specified
tag is an opaque value selected by a particular router, advertising
the plurality of particular routes; wherein the particular router
is different than the first and second routers.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] The appended claims set forth the features of the invention
with particularity. The invention, together with its advantages,
may be best understood from the following detailed description
taken in conjunction with the accompanying drawings of which:
[0022] FIG. 1 is a block diagram of an exemplary system employing
one embodiment;
[0023] FIG. 2A is a block diagram illustrating messages sent and
actions taken in one embodiment;
[0024] FIG. 2B is a block diagram of messages fields used in one
embodiment;
[0025] FIG. 3A is a block diagram illustrating fields used in one
embodiment to advertise a withdrawal of routes by tags (WRBT)
capability; and
[0026] FIG. 3B is a block diagram illustrating fields used in one
embodiment to associate a WRBT identifier with one or more routes,
or to withdraw a specified WRBT identifier.
DETAILED DESCRIPTION
[0027] Disclosed are, inter alia, methods, apparatus, data
structures, computer-readable medium, mechanisms, and means for
withdrawing multiple advertised routes based on a single tag which
may be of particular use in Border Gateway Protocol.
[0028] Embodiments described herein include various elements and
limitations, with no one element or limitation contemplated as
being a critical element or limitation. Each of the claims
individually recites an aspect of the invention in its entirety.
Moreover, some embodiments described may include, but are not
limited to, inter alia, systems, networks, integrated circuit
chips, embedded processors, ASICs, methods, and computer-readable
medium containing instructions. One or multiple systems, devices,
components, etc. may comprise one or more embodiments, which may
include some elements or limitations of a claim being performed by
the same or different systems, devices, components, etc. The
embodiments described hereinafter embody various aspects and
configurations within the scope and spirit of the invention, with
the figures illustrating exemplary and non-limiting
configurations.
[0029] As used herein, the term "packet" refers to packets of all
types or any other units of information or data, including, but not
limited to, fixed length cells and variable length packets, each of
which may or may not be divisible into smaller packets or cells.
The term "packet" as used herein also refers to both the packet
itself or a packet indication, such as, but not limited to all or
part of a packet or packet header, a data structure value, pointer
or index, or any other part or direct or indirect identification of
a packet or information associated therewith. For example, often
times a router operates on one or more fields of a packet,
especially the header, so the body of the packet is often stored in
a separate memory while the packet header is manipulated, and based
on the results of the processing of the packet (i.e., the packet
header in this example), the entire packet is forwarded or dropped,
etc. Additionally, these packets may contain one or more types of
information, including, but not limited to, voice, data, video, and
audio information. The term "item" is used generically herein to
refer to a packet or any other unit or piece of information or
data, a device, component, element, or any other entity. The
phrases "processing a packet" and "packet processing" typically
refer to performing some steps or actions based on the packet
contents (e.g., packet header or other fields), and such steps or
action may or may not include modifying, storing, dropping, and/or
forwarding the packet and/or associated data.
[0030] The term "system" is used generically herein to describe any
number of components, elements, sub-systems, devices, packet switch
elements, packet switches, routers, networks, computer and/or
communication devices or mechanisms, or combinations of components
thereof. The term "computer" is used generically herein to describe
any number of computers, including, but not limited to personal
computers, embedded processing elements and systems, control logic,
ASICs, chips, workstations, mainframes, etc. The term "processing
element" is used generically herein to describe any type of
processing mechanism or device, such as a processor, ASIC, field
programmable gate array, computer, etc. The term "device" is used
generically herein to describe any type of mechanism, including a
computer or system or component thereof. The terms "task" and
"process" are used generically herein to describe any type of
running program, including, but not limited to a computer process,
task, thread, executing application, operating system, user
process, device driver, native code, machine or other language,
etc., and can be interactive and/or non-interactive, executing
locally and/or remotely, executing in foreground and/or background,
executing in the user and/or operating system address spaces, a
routine of a library and/or standalone application, and is not
limited to any particular memory partitioning technique. The steps,
connections, and processing of signals and information illustrated
in the figures, including, but not limited to any block and flow
diagrams and message sequence charts, may typically be performed in
the same or in a different serial or parallel ordering and/or by
different components and/or processes, threads, etc., and/or over
different connections and be combined with other functions in other
embodiments, unless this disables the embodiment or a sequence is
explicitly or implicitly required (e.g., for a sequence of read the
value, process the value--the value must be obtained prior to
processing it, although some of the associated processing may be
performed prior to, concurrently with, and/or after the read
operation). Furthermore, the term "identify" is used generically to
describe any manner or mechanism for directly or indirectly
ascertaining something, which may include, but is not limited to
receiving, retrieving from memory, determining, defining,
calculating, generating, etc.
[0031] Moreover, the terms "network" and "communications mechanism"
are used generically herein to describe one or more networks,
communications mediums or communications systems, including, but
not limited to the Internet, private or public telephone, cellular,
wireless, satellite, cable, local area, metropolitan area and/or
wide area networks, a cable, electrical connection, bus, etc., and
internal communications mechanisms such as message passing,
interprocess communications, shared memory, etc. The term "message"
is used generically herein to describe a piece of information which
may or may not be, but is typically communicated via one or more
communication mechanisms of any type.
[0032] The term "storage mechanism" includes any type of memory,
storage device or other mechanism for maintaining instructions or
data in any format. The term "memory" includes any random access
memory (RAM), read only memory (ROM), flash memory, integrated
circuits, and/or other memory components or elements. The term
"storage device" includes any solid state storage media, disk
drives, diskettes, networked services, tape drives, and other
storage devices. Memories and storage devices may store
computer-executable instructions to be executed by a processing
element and/or control logic, and data which is manipulated by a
processing element and/or control logic. The term "data structure"
is an extensible term referring to any data element, variable, data
structure, database, and/or one or more organizational schemes that
can be applied to data to facilitate interpreting the data or
performing operations on it, such as, but not limited to memory
locations or devices, sets, queues, trees, heaps, lists, linked
lists, arrays, tables, pointers, etc. A data structure is typically
maintained in a storage mechanism. The terms "pointer" and "link"
are used generically herein to identify some mechanism for
referencing or identifying another element, component, or other
entity, and these may include, but are not limited to a reference
to a memory or other storage mechanism or location therein, an
index in a data structure, a value, etc. The term "associative
memory" is an extensible term, and refers to all types of known or
future developed associative memories, including, but not limited
to binary and ternary content addressable memories, hash tables,
TRIE and other data structures, etc. Additionally, the term
"associative memory unit" may include, but is not limited to one or
more associative memory devices or parts thereof, including, but
not limited to regions, segments, banks, pages, blocks, sets of
entries, etc.
[0033] The term "one embodiment" is used herein to reference a
particular embodiment, wherein each reference to "one embodiment"
may refer to a different embodiment, and the use of the term
repeatedly herein in describing associated features, elements
and/or limitations does not establish a cumulative set of
associated features, elements and/or limitations that each and
every embodiment must include, although an embodiment typically may
include all these features, elements and/or limitations. In
addition, the phrase "means for xxx" typically includes
computer-readable medium containing computer-executable
instructions for performing xxx.
[0034] In addition, the terms "first," "second," etc. are typically
used herein to denote different units (e.g., a first element, a
second element). The use of these terms herein does not necessarily
connote an ordering such as one unit or event occurring or coming
before another, but rather provides a mechanism to distinguish
between particular units. Additionally, the use of a singular tense
of a noun is non-limiting, with its use typically including one or
more of the particular thing rather than just one (e.g., the use of
the word "memory" typically refers to one or more memories without
having to specify "memory or memories," or "one or more memories"
or "at least one memory", etc.). Moreover, the phrases "based on x"
and "in response to x" are used to indicate a minimum set of items
x from which something is derived or caused, wherein "x" is
extensible and does not necessarily describe a complete list of
items on which the operation is performed, etc. Additionally, the
phrase "coupled to" is used to indicate some level of direct or
indirect connection between two elements or devices, with the
coupling device or devices modifying or not modifying the coupled
signal or communicated information. The term "subset" is used to
indicate a group of all or less than all of the elements of a set.
The term "subtree" is used to indicate all or less than all of a
tree. Moreover, the term "or" is used herein to identify a
selection of one or more, including all, of the conjunctive
items.
[0035] Disclosed are, inter alia, methods, apparatus, data
structures, computer-readable medium, mechanisms, and means for
withdrawing routes based on a tag. One embodiment receives one or
more messages identifying multiple routes and a tag associated with
the multiple routes. A routing database is updated to include the
routes. A particular message associated with a route withdraw
operation is received, with the particular message including an
indication of the tag. The multiple routes are removed from the
routing database in response to receiving the tag. In one
embodiment, the tag is a Border Gateway Protocol attribute. In one
embodiment, the tag is a Border Gateway Protocol communities
attribute. In one embodiment, before other nodes will send to a
particular device a message to withdraw multiple routes based on a
tag, the particular device must first advertise that it has this
capability and/or it will withdraw multiple routes based on a tag.
In one embodiment, a route may be associated with a single tag. In
one embodiment, a route may be associated with multiple tags.
[0036] One embodiment operates in the context of Border Gateway
Protocol (BGP), and this one embodiment is now described, with
these teachings applicable to other embodiments and other
protocols. When a BGP speaker wishes to withdraw all of the routes
which were advertised with a particular tag (e.g., a path
attribute, community attribute, or other tag value), it may use a
single tag to withdraw multiple routes previously associated with
the tag in lieu of the conventional withdraw mechanism.
[0037] When a BGP speaker advertises a route, it may optionally
advertise it with one or more tags with which it is associated.
This route may or may not have been previously associated with the
tag or even subsequently associated with the tag. If the tag is in
the form of a path attribute, the BGP can maintain the attribute as
it does other attributes. In one embodiment, these tags are stored
in a data structure in a manner to efficiently identify the routes
matching a tag. In one embodiment, an associative or other memory
device is used in storing the associations between tags and
routes.
[0038] In one embodiment, a device advertises that it supports
withdrawal of routes by tags (WRBT). For example, the WRBT
capability may be advertised in a BGP open message, another message
indicating such capability, or in any other manner. The BGP speaker
then processes these communities received from any peer which
similarly has this capability (and usually has advertised this
capability to other nodes, although this is not required).
[0039] An example of such a WRBT capability advertisement 300 used
in one embodiment is shown in FIG. 3A, with WRBT capability
advertisement 300 including a WRBT type code 301 (e.g., a byte with
its value indicating the WRBT capability), and an optional second
byte with its value reserved, and is typically set to zero and
ignored (i.e., to conform with size requirement in a specification
of BGP). Of course, numerous other messages and/or mechanisms can
be used to advertise this capability, as well as it being entered
via a command line or other interface.
[0040] In one embodiment, tags are encoded to correspond with one
or more WRBT communities, such as, but not limited to a
non-transitive IPv4 address specific extended community. FIG. 3B
illustrates a WRBT community message format 320 used in one
embodiment to associate a WRBT identifier with one or more routes,
or to withdraw a specified WRBT identifier. As shown, the value of
the two high order octets 321 of WRBT community message format 320
specifies the type code of the withdraw operation. The W bit 322 is
set to one if the community is being used to indicate a withdraw of
the associated routes (e.g., a withdraw community), and to zero if
the community is being used to associate routes (e.g., an advertise
community). Bits seventeen through nineteen (i.e. field 323) are
reserved, and are typically set to zero and ignored. The WRBT
identifier 324A-B is an opaque quantity assigned by the advertiser.
An all-zeroes WRBT identifier 324A-B is reserved and indicates that
the identifier is not present, and that the other attributes in the
message are to be used to determine which routes are being
withdrawn. It is typically used only when the W bit is set.
[0041] When a BGP speaker advertises a route, it may include one or
more WRBT communities along with that route. The choice of WRBT
identifier is a local matter. Although, in one embodiment, the WRBT
identifier might be related to the BGP identifier of the external
BGP (eBGP) peer which advertised the route. When a BGP speaker
receives a route with a WRBT community, it may maintain an index of
the association between the WRBT identifier and the route, or it
may simply store the WRBT community as it would any other path
attribute.
[0042] When a BGP speaker which has advertised a set of routes
associated with a WRBT identifier wishes to withdraw all of those
routes, it may do so using an update message which contains a
withdraw by tag community listing the WRBT identifier of the routes
to be withdrawn. More than one withdraw by tag community may be
included if multiple sets of routes are to be withdrawn. The
withdraw by tag community has semantics similar to the withdrawn
routes field, in that if feasible NLRI are present in the same
update message, the withdraw operations precede the processing of
feasible NLRI.
[0043] Once a withdraw by tag community has been sent, the
associated WRBT identifier has been removed from use (this follows
from normal BGP procedures). It may be reused in the future. When a
BGP speaker receives an update with a withdraw by tag community, it
typically processes the update as though the associated routes had
been listed in the withdrawn routes portion of a BGP message.
[0044] The withdraw by tag community is typically not transitive.
In particular, withdraw by tag communities are typically not
forwarded by route reflectors or similar devices; the withdraw by
tag community must be regenerated (or stripped) hop-by-hop.
[0045] If a withdraw by tag community is received with the partial
bit of its path attribute set, it is typically ignored, and a
message is typically be logged as this indicates a problem with an
upstream router.
[0046] Routes can be disassociated from WRBT identifiers using the
usual BGP technique of re-advertising the route without the
withdraw by tag announce community. Similarly, a route's WRBT
identifier association can be changed by re-advertising the route
with one or more new withdraw by tag announce communities.
[0047] A BGP speaker may also withdraw a set of routes associated
with any other path attribute or set of path attributes. It does so
by sending an Update message which contains a withdraw by tag
community with a WRBT identifier of zero, and the path attributes
which define the routes being withdrawn. All advertised routes
which are associated with all of the path attributes are considered
withdrawn. For example, an update message containing a withdraw by
tag community with Identifier zero, an AS Path attribute with path
(A, B, C) and a Nexthop attribute with value 10.1.1.1 would result
in all routes with AS Path (A, B, C) AND Nexthop 10.1.1.1 being
withdrawn. Routes with either of the attributes, but not both,
would not be withdrawn. Routes with both of the attributes and
other attributes besides would be withdrawn, regardless of the
values of the additional attributes.
[0048] Note, one embodiment allows routes to be withdrawn using
withdraw by tag operations and/or by using operations other than
withdraw by tag operations (e.g., withdraw by listing each route as
provided for in RFC 1771). The number and/or types of routes that
can be associated with a particular tag is unlimited, and the WRBT
capability is extensible to meet the needs of a particular
application or network configuration. For example, it is typically
important to remove routes without corresponding backup routes
quickly. Thus, a tag may be associated with each route over a link
for which no backup route exists. If this link becomes unavailable,
all of these routes can then be removed with a single WRBT
message.
[0049] FIG. 1 is a block diagram of an exemplary system employing
one embodiment. Illustrated therein are multiple nodes 100,
121-122, and 125 of a network, with at least two of these nodes
supporting withdrawing multiple advertised routes based on a single
tag. A node 100, 121-122, and 125 can be a router or any other
networked device.
[0050] In one embodiment, node 100 includes a processing element
101, memory 102, storage devices 103, and an interface 104 for
receiving and sending packets, items, and/or other information,
which are typically coupled via one or more communications
mechanisms 109 (shown as a bus for illustrative purposes.) Various
embodiments of node 100 may include more or less elements. The
operation of node 100 is typically controlled by processing element
101 using memory 102 and storage devices 103 to perform one or more
scheduling tasks or processes. Memory 102 is one type of
computer-readable medium, and typically comprises random access
memory (RAM), read only memory (ROM), flash memory, integrated
circuits, and/or other memory components. Memory 102 typically
stores computer-executable instructions to be executed by
processing element 101 and/or data which is manipulated by
processing element 101 for implementing functionality in accordance
with the invention. Storage devices 103 are another type of
computer-readable medium, and typically comprise solid state
storage media, disk drives, diskettes, networked services, tape
drives, and other storage devices. Storage devices 103 typically
store computer-executable instructions to be executed by processing
element 101 and/or data which is manipulated by processing element
101 for implementing functionality in accordance with the
invention.
[0051] FIG. 2A is a block diagram illustrating messages sent and
actions taken in one embodiment. Shown in FIG. 2A is the processing
and sending of messages between node-A 200 and node-B 210.
[0052] Typically, a node-B 210 will advertise to other nodes its
capability to support withdraw by tag operations, especially in a
heterogeneous network where some devices support this feature and
some devices do not. It is expected that should this feature be
pervasive or otherwise readily supported, there will no longer be
the need to advertise this capability as it will be inherent and
possibly provided for in a future specification of a protocol. As
shown, node-B 210 sends message 201 advertising its support for
withdraw of routes based on tags. In one embodiment, in response to
message 201, node-A 200 updates one or more data structures to
identify that node-B 210 supports withdraw by tag operations.
[0053] At some point in time, node-A 200 sends a message 205 which
is received by node-B 210. Message 205 identifies one or more
routes and their associated tag(s). Note, this association message
205 may or may not be the same message that advertises the routes
to node-B 210. In response, node-B 210 updates one or more data
structures to associate the tags(s) with the routes, and if the
routes were advertised, typically processes these route
advertisements as normal.
[0054] Node-A, at some point typically later in time, sends a
message 207 to node-B 210 which includes an indication to withdraw
the one or more routes identified by the tag. In response, node-B
210 identifies the particular routes based on the tag and withdraws
them. In one embodiment, node-B 210, in response to message 207,
removes the tag from its data structure. In one embodiment, node-B
210, in response to message 207, does not remove the tag physically
from its data structure, but rather logically removes the
association. Thus, in one embodiment, a message with the same tag
could be received by node-B 210 indicating to add (e.g., make
available) these previously logically removed routes.
[0055] FIG. 2B is a block diagram of messages fields used in one
embodiment. Tag support message field 220 is included in a message
format supported by the one embodiment. It can be a separate
message, or the tag support message field 220 included in another
message. Typically, tag support message field 220 includes some
value that will be interpreted by a received node as an indication
that the sending node supports withdraw by tag operations.
[0056] Also shown in FIG. 2B is tag operation message fields 230,
which are used to associate tags with routes and/or withdraw routes
based on a specified tag. Tag support message field 230 is included
in a message format supported by the one embodiment. It can be a
separate message, or one or more of tag operations message fields
230 can be included in another message. Typically, tag support
message field 230 includes one or more fields 231-234. To associate
routes with tags, message field 231 typically specifies one or more
routes and message field 234 specifies one or more tags, with field
232 indicating a tag operation, and field 233 indicating a tag
association operation. To withdraw one or more routes associated
with a tag, tag field 234 specifies the tag(s), with field 232
indicating a tag operation, field 233 indicating a tag withdraw
operation, and field 231 typically being ignored or not included in
the message.
[0057] In view of the many possible embodiments to which the
principles of our invention may be applied, it will be appreciated
that the embodiments and aspects thereof described herein with
respect to the drawings/figures are only illustrative and should
not be taken as limiting the scope of the invention. For example
and as would be apparent to one skilled in the art, many of the
process block operations can be re-ordered to be performed before,
after, or substantially concurrent with other operations. Also,
many different forms of data structures could be used in various
embodiments. The invention as described herein contemplates all
such embodiments as may come within the scope of the following
claims and equivalents thereof.
* * * * *