RFC1863 日本語訳
1863 A BGP/IDRP Route Server alternative to a full mesh routing. D.Haskin. October 1995. (Format: TXT=37426 bytes) (Obsoleted by RFC4223) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Haskin Request For Comments: 1863 Bay Networks, Inc. Category: Experimental October 1995
Network Working Group D. Haskin Request For Comments: 1863 Bay Networks, Inc. Category: Experimental October 1995
A BGP/IDRP Route Server alternative to a full mesh routing
A BGP/IDRP Route Server alternative to a full mesh routing
Status of this Memo
Status of this Memo
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Abstract
Abstract
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
This document describes the use and detailed design of Route Servers for dissemination of routing information among BGP/IDRP speaking routers.
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud).
The intention of the proposed technique is to reduce overhead and management complexity of maintaining numerous direct BGP/IDRP sessions which otherwise might be required or desired among routers within a single routing domain as well as among routers in different domains that are connected to a common switched fabric (e.g. an ATM cloud).
1. Overview
1. Overview
Current deployments of Exterior Routing protocols, such as the Border Gateway Protocol [BGP4] and the adaptation of the ISO Inter-Domain Routing Protocol [IDRP], require that all BGP/IDRP routers, which participate in inter-domain routing (border routers) and belong to the same routing domain, establish a full mesh connectivity with each other for purpose of exchanging routing information acquired from other routing domains. In large routing domains the number of intra- domain connections that needs to be maintained by each border route can be significant.
Current deployments of Exterior Routing protocols, such as the Border Gateway Protocol [BGP4] and the adaptation of the ISO Inter-Domain Routing Protocol [IDRP], require that all BGP/IDRP routers, which participate in inter-domain routing (border routers) and belong to the same routing domain, establish a full mesh connectivity with each other for purpose of exchanging routing information acquired from other routing domains. In large routing domains the number of intra- domain connections that needs to be maintained by each border route can be significant.
In addition, it may be desired for a border router to establish routing sessions with all border routers in other domains which are reachable via a shared communication media. We refer to routers that are directly reachable via a shared media as adjacent routers. Such direct peering allows a router to acquire "first hand" information about destinations which are directly reachable through adjacent routers and select the optimum direct paths to these destinations. Establishment of BGP/IDRP sessions among all adjacent border routers would result in a full mesh routing connectivity. Unfortunately for
In addition, it may be desired for a border router to establish routing sessions with all border routers in other domains which are reachable via a shared communication media. We refer to routers that are directly reachable via a shared media as adjacent routers. Such direct peering allows a router to acquire "first hand" information about destinations which are directly reachable through adjacent routers and select the optimum direct paths to these destinations. Establishment of BGP/IDRP sessions among all adjacent border routers would result in a full mesh routing connectivity. Unfortunately for
Haskin Experimental [Page 1] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 1] RFC 1863 A BGP/IDRP Route Server October 1995
a switched media as ATM, SMDS or Frame Relay network which may inter-connect a large number of routers, due to the number of connections that would be needed to maintain a full mesh direct peering between the routers, makes this approach impractical.
a switched media as ATM, SMDS or Frame Relay network which may inter-connect a large number of routers, due to the number of connections that would be needed to maintain a full mesh direct peering between the routers, makes this approach impractical.
In order to alleviate the "full mesh" problem, this paper proposes to use IDRP/BGP Route Servers which would relay external routes with all of their attributes between client routers. The clients would maintain IDRP/BGP sessions only with the assigned route servers (sessions with more than one server would be needed if redundancy is desired). All routes that are received from a client router would be propagated to other clients by the Route Server. Since all external routes and their attributes are relayed unmodified between the client routers, the client routers would acquire the same routing information as they would via direct peering. We refer to such arrangement as virtual peering. Virtual peering allows client routers independently apply selection criteria to the acquired external routes according to their local policies as they would if a direct peering were established.
In order to alleviate the "full mesh" problem, this paper proposes to use IDRP/BGP Route Servers which would relay external routes with all of their attributes between client routers. The clients would maintain IDRP/BGP sessions only with the assigned route servers (sessions with more than one server would be needed if redundancy is desired). All routes that are received from a client router would be propagated to other clients by the Route Server. Since all external routes and their attributes are relayed unmodified between the client routers, the client routers would acquire the same routing information as they would via direct peering. We refer to such arrangement as virtual peering. Virtual peering allows client routers independently apply selection criteria to the acquired external routes according to their local policies as they would if a direct peering were established.
The routing approach described in this paper assumes that border routers possess a mechanism to resolve the media access address of the next hop router for any route acquired from a virtual peer.
The routing approach described in this paper assumes that border routers possess a mechanism to resolve the media access address of the next hop router for any route acquired from a virtual peer.
It is fair to note that the approach presented in this paper only reduces the number of routing connection each border router needs to maintain. It does not reduce the volume of routing information that needs to maintained at each border router.
It is fair to note that the approach presented in this paper only reduces the number of routing connection each border router needs to maintain. It does not reduce the volume of routing information that needs to maintained at each border router.
Besides addressing the "full mesh" problems, the proposal attempts to achieve the following goals:
Besides addressing the "full mesh" problems, the proposal attempts to achieve the following goals:
- to minimize BGP/IDRP changes that need to be implemented in client
routers in order to inter-operate with route servers;
- to minimize BGP/IDRP changes that need to be implemented in client routers in order to inter-operate with route servers;
- to provide for redundancy of distribution of routing information to
route server clients;
- to provide for redundancy of distribution of routing information to route server clients;
- to minimize the amount of routing updates that have to be sent to
route server clients;
- to minimize the amount of routing updates that have to be sent to route server clients;
- to provide load distribution between route servers;
- to provide load distribution between route servers;
- to avoid an excessive complexity of the interactions between Route
Servers themselves.
- to avoid an excessive complexity of the interactions between Route Servers themselves.
Haskin Experimental [Page 2] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 2] RFC 1863 A BGP/IDRP Route Server October 1995
2. Terms And Acronyms
2. Terms And Acronyms
The following terms and acronyms are used in this paper:
The following terms and acronyms are used in this paper:
Routing Domain - a collection of routers with the same set of
routing policies. For IPv4 it can be identified
with an Autonomous System Number, for IPv6
it can be identified with a Routing Domain
Identifier.
Routing Domain - a collection of routers with the same set of routing policies. For IPv4 it can be identified with an Autonomous System Number, for IPv6 it can be identified with a Routing Domain Identifier.
Border Router (BR) - a router that acquires external routes, i.e.
routes to internet points outside its routing
domain.
Border Router (BR) - a router that acquires external routes, i.e. routes to internet points outside its routing domain.
Route Server (RS) - a process that collects routing information
from border routers and distributes this
information to 'client routers'.
Route Server (RS) - a process that collects routing information from border routers and distributes this information to 'client routers'.
RS Client (RC) - a router than peers with an RS in order to
acquire routing information. A server's client
can be a router or another route server.
RS Client (RC) - a router than peers with an RS in order to acquire routing information. A server's client can be a router or another route server.
RS Cluster (RSC) - two or more of route servers that share the same
subset of clients. A RS Cluster provides
redundancy of routing information to its
clients, i.e. routing information is provided
to all RS Cluster clients as long as there is
at least one functional route server in the RS
Cluster.
RS Cluster (RSC) - two or more of route servers that share the same subset of clients. A RS Cluster provides redundancy of routing information to its clients, i.e. routing information is provided to all RS Cluster clients as long as there is at least one functional route server in the RS Cluster.
RCID - Cluster ID
RCID - Cluster ID
3. RS Model
3. RS Model
In the proposed scheme a Route Server (RS) does not apply any selection criteria to the routes received from border routers for the purpose of distributing these routes to its clients. All routes acquired from border routers or other Route Servers are relayed to the client border routers.
In the proposed scheme a Route Server (RS) does not apply any selection criteria to the routes received from border routers for the purpose of distributing these routes to its clients. All routes acquired from border routers or other Route Servers are relayed to the client border routers.
There can be two classes of Route Servers: Route Servers that relay external routes between routers in a single routing domain and Route Servers that relay external routes between border routers in different routing domains. The former are Intra-Domain Route Servers and the latter are Inter-Domain Route Servers.
There can be two classes of Route Servers: Route Servers that relay external routes between routers in a single routing domain and Route Servers that relay external routes between border routers in different routing domains. The former are Intra-Domain Route Servers and the latter are Inter-Domain Route Servers.
In the RS model proposed in this document there is no routing exchange between Intra-Domain Route Servers and Inter-Domain Route
In the RS model proposed in this document there is no routing exchange between Intra-Domain Route Servers and Inter-Domain Route
Haskin Experimental [Page 3] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 3] RFC 1863 A BGP/IDRP Route Server October 1995
Servers. Routes that cross a domain boundary must always pass through a border router of such a domain which may apply administrative filters to such routes.
Servers. Routes that cross a domain boundary must always pass through a border router of such a domain which may apply administrative filters to such routes.
Operations of Intra-Domain Route Servers and Inter-Domain Route Servers are identical.
Operations of Intra-Domain Route Servers and Inter-Domain Route Servers are identical.
One or more Route Servers form an RS Cluster (RSC). For redundancy's sake two or more RSs can be configured to operate in an RS Cluster. All route servers in an RSC share the same clients, i.e. cluster clients establish connections to all route servers in such an RSC for the purpose of exchanging routing information. Each cluster is assigned an unique RSC Identifier (RCID) represented by a 2-octet unsigned integer.
One or more Route Servers form an RS Cluster (RSC). For redundancy's sake two or more RSs can be configured to operate in an RS Cluster. All route servers in an RSC share the same clients, i.e. cluster clients establish connections to all route servers in such an RSC for the purpose of exchanging routing information. Each cluster is assigned an unique RSC Identifier (RCID) represented by a 2-octet unsigned integer.
Clusters which provide virtual connectivity between their clients would be normally exchanging routing information among themselves so that all external routes are propagated to all participating clients.
Clusters which provide virtual connectivity between their clients would be normally exchanging routing information among themselves so that all external routes are propagated to all participating clients.
Though a Route Server Client (RC) can be associated with multiple RSC, it seems that there is no real advantage of doing so except for a short transition period to provide a graceful re-assignment from one RSC to another or, if for some reason, there are multiple RS groups that don't exchange routing information with each other.
Though a Route Server Client (RC) can be associated with multiple RSC, it seems that there is no real advantage of doing so except for a short transition period to provide a graceful re-assignment from one RSC to another or, if for some reason, there are multiple RS groups that don't exchange routing information with each other.
The inter-cluster route exchange can be accomplished by forming a full mesh routing adjacency between clusters. In this approach, illustrated in the diagram below, each RS in each RSC would maintain a routing connection with every RS in other RS clusters. Only routes that are acquired from border routers are propagated to RSs in other RS clusters.
The inter-cluster route exchange can be accomplished by forming a full mesh routing adjacency between clusters. In this approach, illustrated in the diagram below, each RS in each RSC would maintain a routing connection with every RS in other RS clusters. Only routes that are acquired from border routers are propagated to RSs in other RS clusters.
BR11 BR12 BR1n BR21 BR22 BR2n
| | ... | | | ... |
----------------- ------------------
! RS11 RS12 ! --- ! RS21 RS22 !
----------------- ------------------
<RSC#1> \ / <RSC#2>
\ /
-----------------
! RS31 RS32 ! <RSC#3>
-----------------
| | ... |
BR31 BR32 BR3n
BR11 BR12 BR1n BR21 BR22 BR2n | | ... | | | ... | ----------------- ------------------ ! RS11 RS12 ! --- ! RS21 RS22 ! ----------------- ------------------ <RSC#1> \ / <RSC#2> \ / ----------------- ! RS31 RS32 ! <RSC#3> ----------------- | | ... | BR31 BR32 BR3n
Another way to propagate routing information between clusters would be to form a cluster hierarchy in which an RS in one cluster maintains sessions only with RSs in designated clusters. In this
Another way to propagate routing information between clusters would be to form a cluster hierarchy in which an RS in one cluster maintains sessions only with RSs in designated clusters. In this
Haskin Experimental [Page 4] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 4] RFC 1863 A BGP/IDRP Route Server October 1995
approach an RS must advertise all acquired routes to an RS in another cluster except the routes that are acquired from that cluster. Nevertheless, it allows for minimizing the number of routing sessions which can be highly desirable in some network. It is important for the hierarchical scheme that the inter-cluster route exchange links form a tree, i.e. there is only one route propagation path between any two clusters, otherwise routing loops may result. For detection and pruning of routing loops in a hierarchical cluster topology, it is advisable to include the "RCID Path" attribute (see 4.3.4) in all routing updates sent between route servers. This attribute lists IDs of all clusters in the route propagation path. When a duplicate ID is detected in this attribute an offending route needs to be discarded.
approach an RS must advertise all acquired routes to an RS in another cluster except the routes that are acquired from that cluster. Nevertheless, it allows for minimizing the number of routing sessions which can be highly desirable in some network. It is important for the hierarchical scheme that the inter-cluster route exchange links form a tree, i.e. there is only one route propagation path between any two clusters, otherwise routing loops may result. For detection and pruning of routing loops in a hierarchical cluster topology, it is advisable to include the "RCID Path" attribute (see 4.3.4) in all routing updates sent between route servers. This attribute lists IDs of all clusters in the route propagation path. When a duplicate ID is detected in this attribute an offending route needs to be discarded.
The diagram below which illustrates the hierarchical approach is created from the diagram above by removing the route exchange link between clusters 2 and 3.
The diagram below which illustrates the hierarchical approach is created from the diagram above by removing the route exchange link between clusters 2 and 3.
BR11 BR12 BR1n BR21 BR22 BR2n
| | ... | | | ... |
----------------- ------------------
! RS11 RS12 ! --- ! RS21 RS22 !
----------------- ------------------
<RSC#1> \ <RSC#2>
\
-----------------
! RS31 RS32 ! <RSC#3>
-----------------
| | ... |
BR31 BR32 BR3n
BR11 BR12 BR1n BR21 BR22 BR2n | | ... | | | ... | ----------------- ------------------ ! RS11 RS12 ! --- ! RS21 RS22 ! ----------------- ------------------ <RSC#1> \ <RSC#2> \ ----------------- ! RS31 RS32 ! <RSC#3> ----------------- | | ... | BR31 BR32 BR3n
It seems that the only disadvantage of the hierarchical model, is the management headache of avoiding routing loops and redundant information flow by insuring that inter-cluster links always form a tree. But more study is needed to fully evaluate the comparative merits of the full-mesh and hierarchical models.
It seems that the only disadvantage of the hierarchical model, is the management headache of avoiding routing loops and redundant information flow by insuring that inter-cluster links always form a tree. But more study is needed to fully evaluate the comparative merits of the full-mesh and hierarchical models.
Since RSs in the same cluster maintain routing sessions with the same set of clients, it may seem that there is no need to exchange routing information between RSs in the same cluster. Nevertheless, such a route exchange may help to maintain identical routing databases in the servers during client acquisition periods and when a partial failure may affect some routing sessions.
Since RSs in the same cluster maintain routing sessions with the same set of clients, it may seem that there is no need to exchange routing information between RSs in the same cluster. Nevertheless, such a route exchange may help to maintain identical routing databases in the servers during client acquisition periods and when a partial failure may affect some routing sessions.
Route servers in the same RS cluster exchange control messages in attempt to subdivide the responsibilities of providing routing information to their clients. In order to simplify the RS design, the RS messaging is implemented on top of exterior protocol which is
Route servers in the same RS cluster exchange control messages in attempt to subdivide the responsibilities of providing routing information to their clients. In order to simplify the RS design, the RS messaging is implemented on top of exterior protocol which is
Haskin Experimental [Page 5] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 5] RFC 1863 A BGP/IDRP Route Server October 1995
used by route servers for the routing information exchange.
used by route servers for the routing information exchange.
4. Operation
4. Operation
4.1 ADVERTISER Path Attribute
4.1 ADVERTISER Path Attribute
Route servers act as concentrators for routes acquired by border routers so that the border routers need to maintain routing connections with only one or two designated route servers. Route Servers distribute routing information that is provided to them by the border routers to all their client.
Route servers act as concentrators for routes acquired by border routers so that the border routers need to maintain routing connections with only one or two designated route servers. Route Servers distribute routing information that is provided to them by the border routers to all their client.
If routing information were relayed to RS clients in UPDATE messages with only those path attribute that are currently defined in the BGP-4/IDRP specification, the RS clients would not be able to associate external routes they receive with the border routers which submitted that routes to route servers. Such an association is necessary for making a correct route selection decision. Therefore, the new path attribute, ADVERTISER, is defined.
If routing information were relayed to RS clients in UPDATE messages with only those path attribute that are currently defined in the BGP-4/IDRP specification, the RS clients would not be able to associate external routes they receive with the border routers which submitted that routes to route servers. Such an association is necessary for making a correct route selection decision. Therefore, the new path attribute, ADVERTISER, is defined.
The ADVERTISER is an optional non-transitive attribute that defines the identifying address of the border router which originally submitted the route to a router server in order for it to be relayed to other RS clients. Type Code of the ADVERTISER attribute is 255. This attribute must be included in every UPDATE message that is relayed by route servers and must be recognized by RS clients.
The ADVERTISER is an optional non-transitive attribute that defines the identifying address of the border router which originally submitted the route to a router server in order for it to be relayed to other RS clients. Type Code of the ADVERTISER attribute is 255. This attribute must be included in every UPDATE message that is relayed by route servers and must be recognized by RS clients.
4.2 Route Client Operation
4.2 Route Client Operation
An RS client establishes an BGP/IDRP connection to every route server in the RS cluster to which the route client is assigned.
An RS client establishes an BGP/IDRP connection to every route server in the RS cluster to which the route client is assigned.
RS clients must be able to recognize the ADVERTISER path attribute that is included in all UPDATE messages received from route servers. Routes received in UPDATE messages from route servers are processed as if they were received directly from the border routers specified in the ADVERTISER attributes of the respective updates.
RS clients must be able to recognize the ADVERTISER path attribute that is included in all UPDATE messages received from route servers. Routes received in UPDATE messages from route servers are processed as if they were received directly from the border routers specified in the ADVERTISER attributes of the respective updates.
If an RS client receives a route from a Intra-Domain Route Server, is assumed that the border router identified in the ADVERTISER attribute is located in the receiving client's own routing domain.
If an RS client receives a route from a Intra-Domain Route Server, is assumed that the border router identified in the ADVERTISER attribute is located in the receiving client's own routing domain.
If an RS client receives a route from a Inter-Domain Route Server, the locality of the border router identified in the ADVERTISER attribute can be determined from the BGP's AS_PATH attribute or IDRP's RD_PATH attribute respectively.
If an RS client receives a route from a Inter-Domain Route Server, the locality of the border router identified in the ADVERTISER attribute can be determined from the BGP's AS_PATH attribute or IDRP's RD_PATH attribute respectively.
Haskin Experimental [Page 6] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 6] RFC 1863 A BGP/IDRP Route Server October 1995
If no ADVERTISER attribute was included in an UPDATE message from a route server it is assumed that the route server itself is the advertiser of the corresponding route.
If no ADVERTISER attribute was included in an UPDATE message from a route server it is assumed that the route server itself is the advertiser of the corresponding route.
If the NEXT_HOP path attribute of an UPDATE message lists an address of the receiving router itself, the route that is carried in such an update message must be declared unreachable.
If the NEXT_HOP path attribute of an UPDATE message lists an address of the receiving router itself, the route that is carried in such an update message must be declared unreachable.
In addition, it is highly desirable, albeit not required, to slightly modify the "standard" BGP/IDRP operation when acquiring routes from RSs:
In addition, it is highly desirable, albeit not required, to slightly modify the "standard" BGP/IDRP operation when acquiring routes from RSs:
when a route is received from an RS and a route with the completely
identical attributes has been previously acquired from another RS
in the same cluster, the previously acquired route should be
replaced with the newly acquired route. Such a route replacement
should not trigger any route advertisement action on behalf of the
route.
when a route is received from an RS and a route with the completely identical attributes has been previously acquired from another RS in the same cluster, the previously acquired route should be replaced with the newly acquired route. Such a route replacement should not trigger any route advertisement action on behalf of the route.
RSs are designed to operate in such a way that eliminates the need to keep multiple copies of the same route by RS clients and minimizes the possibility of a route flap when the BGP/IDRP connection to one of the redundant route servers is lost.
RSs are designed to operate in such a way that eliminates the need to keep multiple copies of the same route by RS clients and minimizes the possibility of a route flap when the BGP/IDRP connection to one of the redundant route servers is lost.
It is attempted to subdivide the route dissemination load between route servers such that only one RS provides routing updates to a given client. But since, for avoiding an excessive complexity, the reconciliation algorithm does not eliminate completely the possibility of races, it is still possible that a client may receive updates from more than one route server. Therefore, the client's ability to discard duplicate routes may reduce the need for a bigger routing database.
It is attempted to subdivide the route dissemination load between route servers such that only one RS provides routing updates to a given client. But since, for avoiding an excessive complexity, the reconciliation algorithm does not eliminate completely the possibility of races, it is still possible that a client may receive updates from more than one route server. Therefore, the client's ability to discard duplicate routes may reduce the need for a bigger routing database.
4.3 Route Server Operation
4.3 Route Server Operation
A Route Server maintains BGP-4/IDRP sessions with its clients according to the respective BGP-4/IDRP specification with exception of protocol modifications outlined in this document.
A Route Server maintains BGP-4/IDRP sessions with its clients according to the respective BGP-4/IDRP specification with exception of protocol modifications outlined in this document.
UPDATE messages sent by route servers have the same format and semantics as it respective BGP-4/IDRP counterparts but also carry the ADVERTISER path attribute which specifies the BGP Identifier of the border router that submitted the route advertised in the UPDATE message. In addition, if the hierarchical model is deployed to interconnect Route Server clusters, it is advisable to include the "RCID Path" attribute in all routing updates sent between route servers as described in 4.3.4.
UPDATE messages sent by route servers have the same format and semantics as it respective BGP-4/IDRP counterparts but also carry the ADVERTISER path attribute which specifies the BGP Identifier of the border router that submitted the route advertised in the UPDATE message. In addition, if the hierarchical model is deployed to interconnect Route Server clusters, it is advisable to include the "RCID Path" attribute in all routing updates sent between route servers as described in 4.3.4.
Haskin Experimental [Page 7] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 7] RFC 1863 A BGP/IDRP Route Server October 1995
When route servers exchange OPEN messages they include the Route Server protocol version (current version is 1) as well as Cluster IDs of their respective clusters in an Optional Parameter of the OPEN message. The value of Parameter Type for this parameter is 255. The length of the parameter data is 3 octets. The format of parameter data is shown below:
When route servers exchange OPEN messages they include the Route Server protocol version (current version is 1) as well as Cluster IDs of their respective clusters in an Optional Parameter of the OPEN message. The value of Parameter Type for this parameter is 255. The length of the parameter data is 3 octets. The format of parameter data is shown below:
+-----------------------+------------------------------------+
| Version = 1 (1 octet) | Cluster ID (2 octets) |
+-----------------------+------------------------------------+
+-----------------------+------------------------------------+ | Version = 1 (1 octet) | Cluster ID (2 octets) | +-----------------------+------------------------------------+
Also, route servers that belong to the same cluster send to each other LIST messages with lists of clients to which they're providing routing information. In the LIST message an RS specifies the Router Identifier of each client to which that RS is providing routing updates. Since LIST messages are relatively small there is no need to add a processing complexity of generating incremental updates when a list changes; instead the complete list is sent when RSs need to be informed of the changes. The format of the LIST message is presented in 4.3.1.
Also, route servers that belong to the same cluster send to each other LIST messages with lists of clients to which they're providing routing information. In the LIST message an RS specifies the Router Identifier of each client to which that RS is providing routing updates. Since LIST messages are relatively small there is no need to add a processing complexity of generating incremental updates when a list changes; instead the complete list is sent when RSs need to be informed of the changes. The format of the LIST message is presented in 4.3.1.
4.3.1 LIST Message Format
4.3.1 LIST Message Format
The LIST message contains the fixed BGP/IDRP header that is followed with the fields shown below. The type code in the fixed header of the LIST message is 255.
The LIST message contains the fixed BGP/IDRP header that is followed with the fields shown below. The type code in the fixed header of the LIST message is 255.
+----------+----------+----------+----------+
| Client Identifying Address | Repeated for each
+-------------------------------------------+ informed client
The number of Client Identifying Address" fields is not encoded
explicitly, but can be calculated as:
+----------+----------+----------+----------+ | Client Identifying Address | Repeated for each +-------------------------------------------+ informed client The number of Client Identifying Address" fields is not encoded explicitly, but can be calculated as:
(<LIST message Length> - <Header Length>) / <Address Length>,
(<LIST message Length> - <Header Length>) / <Address Length>,
where <LIST message Length> is the value encoded in the fixed BGP/IDRP header, <Header Length> is the length of that header, and <Address Length> is 4 for IPv4 and 16 for IPv6.
where <LIST message Length> is the value encoded in the fixed BGP/IDRP header, <Header Length> is the length of that header, and <Address Length> is 4 for IPv4 and 16 for IPv6.
4.3.2 External Route Acquisition And Advertisement
4.3.2 External Route Acquisition And Advertisement
A route server acquires external routes from RS clients that are also border routers. A RS also may acquire external routes from other RSs. Route servers relay all acquired routes unaltered to their clients. No route selection is performed for purpose of route re- advertisement to RS clients.
A route server acquires external routes from RS clients that are also border routers. A RS also may acquire external routes from other RSs. Route servers relay all acquired routes unaltered to their clients. No route selection is performed for purpose of route re- advertisement to RS clients.
Haskin Experimental [Page 8] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 8] RFC 1863 A BGP/IDRP Route Server October 1995
While route servers receive and store routing data from all their client, Routing Servers in the same cluster coordinate their route advertisement in the attempt to ensure that only one RS provides routing updates to a given client. If an RS fails, other Route Servers in the cluster take over the responsibility of providing routing updates to the clients that were previously served by the failed RS. A route flap that can result from such switch-over can be eliminated by the configuring client's "Hold Time" of their BGP- 4/IDRP sessions with the route servers to be larger than the switch- over time. The switch-over time is determined by the Hold Time of BGP-4/IDRP sessions between the route servers in the cluster and the period that is needed for that route servers to reconcile their route advertisement responsibilities. The reconciliation protocol is described in 4.3.3.
While route servers receive and store routing data from all their client, Routing Servers in the same cluster coordinate their route advertisement in the attempt to ensure that only one RS provides routing updates to a given client. If an RS fails, other Route Servers in the cluster take over the responsibility of providing routing updates to the clients that were previously served by the failed RS. A route flap that can result from such switch-over can be eliminated by the configuring client's "Hold Time" of their BGP- 4/IDRP sessions with the route servers to be larger than the switch- over time. The switch-over time is determined by the Hold Time of BGP-4/IDRP sessions between the route servers in the cluster and the period that is needed for that route servers to reconcile their route advertisement responsibilities. The reconciliation protocol is described in 4.3.3.
The BGP-4/IDRP operations of route servers differs from the "standard" operation in the following ways:
The BGP-4/IDRP operations of route servers differs from the "standard" operation in the following ways:
- when receiving routes from another RS, the RS Client mode of
operation is assumed, i.e., when a route with completely
identical attributes has been previously acquired from an RS
belonging to the same cluster as the RS that advertises the new
route, the previously acquired route should be discarded and
the newly acquired route should be accepted. Such a route
replacement should not trigger any route advertisement action
on behalf of the route.
- when receiving routes from another RS, the RS Client mode of operation is assumed, i.e., when a route with completely identical attributes has been previously acquired from an RS belonging to the same cluster as the RS that advertises the new route, the previously acquired route should be discarded and the newly acquired route should be accepted. Such a route replacement should not trigger any route advertisement action on behalf of the route.
- all acquired routes are advertised to a client router except
routes which were acquired from that client (no route echoing);
- all acquired routes are advertised to a client router except routes which were acquired from that client (no route echoing);
- if the hierarchical model of inter-cluster route exchange is
used, all acquired routes are advertised to an RS in another
RSC except routes that are acquired from that RSC. In the
full-mesh model, only routes which are acquired from border
routers are advertised to route servers in other clusters;
- if the hierarchical model of inter-cluster route exchange is used, all acquired routes are advertised to an RS in another RSC except routes that are acquired from that RSC. In the full-mesh model, only routes which are acquired from border routers are advertised to route servers in other clusters;
- if route servers in the same RS cluster are configured to
exchange routing information, only external routes that are
acquired from border routers are advertised to route servers in
the local cluster;
- if route servers in the same RS cluster are configured to exchange routing information, only external routes that are acquired from border routers are advertised to route servers in the local cluster;
- the ADVERTISER path attribute is included in every UPDATE
messages that is generated by RS. This attribute must
specify the identifying address of the border router from which
information provided in UPDATE has been acquired. All other
routing attributes should be relayed to RS's peers unaltered.
- the ADVERTISER path attribute is included in every UPDATE messages that is generated by RS. This attribute must specify the identifying address of the border router from which information provided in UPDATE has been acquired. All other routing attributes should be relayed to RS's peers unaltered.
Haskin Experimental [Page 9] RFC 1863 A BGP/IDRP Route Server October 1995
Haskin Experimental [Page 9] RFC 1863 A BGP/IDRP Route Server October 1995
- when a route advertised by to an RS by a client becomes
unreachable such a route needs to be declared unreachable to
all other clients. In order to withdraw a route, the route
server sends an UPDATE for that route to each client (except
the client that this route was originally acquired) with the
NEXT_HOP path attribute set to the address of the client to
which this UPDATE is sent to. The the ADVERTISER path attribute
with the identifying address of the border router that
originally advertised the withdrawn route must be also included
in such an update message.
- when a route advertised by to an RS by a client becomes unreachable such a route needs to be declared unreachable to all other clients. In order to withdraw a route, the route server sends an UPDATE for that route to each client (except the client that this route was originally acquired) with the NEXT_HOP path attribute set to the address of the client to which this UPDATE is sent to. The the ADVERTISER path attribute with the identifying address of the border router that originally advertised the withdrawn route must be also included in such an update message.
- if the hierarchical model is deployed to interconnect Route
Server clusters, it is advisable to include the RCID_PATH
attribute in all routing updates sent between route servers as
described in 4.3.4. The RCID_PATH attribute is never included
in UPDATE messages sent to border routers.
- if the hierarchical model is deployed to interconnect Route Server clusters, it is advisable to include the RCID_PATH attribute in all routing updates sent between route servers as described in 4.3.4. The RCID_PATH attribute is never included in UPDATE messages sent to border routers.
4.3.3 Intra-Cluster Coordination
4.3.3 Intra-Cluster Coordination
In order to coordinate route advertisement activities, route servers which are members of the same RS cluster establish and maintain BGP/IDRP connections between themselves forming a full-mesh connectivity. Normally, there is no need for more than two-three route servers in one cluster.
In order to coordinate route advertisement activities, route servers which are members of the same RS cluster establish and maintain BGP/IDRP connections between themselves forming a full-mesh connectivity. Normally, there is no need for more than two-three route servers in one cluster.
Route servers belonging to the same cluster send to each other LIST messages with lists of clients to which they're providing routing information; let's call such clients "informed clients".
Route servers belonging to the same cluster send to each other LIST messages with lists of clients to which they're providing routing information; let's call such clients "informed clients".
Each RS maintains a separate "informed client" list for each RS in the local cluster including itself. All such lists are linked in an ascending order that is determined by the number of clients in each list; the order among the lists with the same number of clients is determined by comparing the identifying addresses of the corresponding RSs -- an RS in such a "same number of clients" subset is positioned after all RSs with the lower address.
Each RS maintains a separate "informed client" list for each RS in the local cluster including itself. All such lists are linked in an ascending order that is determined by the number of clients in each list; the order among the lists with the same number of clients is determined by comparing the identifying addresses of the corresponding RSs -- an RS in such a "same number of clients" subset is positioned after all RSs with the lower address.
An RS can be in one of two RS coordination states: 'Initiation' and 'Active'.
An RS can be in one of two RS coordination states: 'Initiation' and 'Active'.
4.3.3.1 Initiation State
4.3.3.1 Initiation State
This is the initial state of route server that is entered upon RS startup. When the Initiation state is entered the 'InitiationTimer' is started. The Initiation state transits to the Active state upon expiration of the 'InitiationTimer' or as soon as all configured BGP/IDRP connections to other route servers in the local RS Cluster are established and LIST messages from that route servers are
これはRS始動のときに入れられるルートサーバの初期状態です。 Initiation状態が入られるとき、'InitiationTimer'は始められます。 地方のRS Clusterの他のルートサーバとのすべての構成されたBGP/IDRP接続が確立されて、それからのLISTメッセージがサーバを発送するようにActiveへの州のトランジットが'InitiationTimer'の同じくらい満了か同じくらいすぐ述べるInitiationがあります。
Haskin Experimental [Page 10] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[10ページ]のRFC1863
received.
受け取られている。
In the Initiation state an RS:
Initiationでは、RSを述べてください:
o tries to establish connections with other RSs in the local and
remote clusters.
o 地方の、そして、リモートなクラスタの他のRSsと共に関係を樹立しようとします。
o accepts BGP/IDRP connections from client routers.
o クライアントルータからBGP/IDRP接続を受け入れます。
o receives and process BGP/IDRP updates but doesn't send any
routing updates.
o 受信して、BGP/IDRPアップデートを処理しますが、どんなルーティングアップデートも送りません。
o stores "informed client" lists received from other RSs in the
local cluster - a newly received list replaces the existing list
for the same RS. If a LIST message is received from the route
server in another RS cluster, it should be silently ignored.
o 「知識があるクライアント」リストが地方のクラスタの他のRSsから受けた店--新たに受け取られたリストは同じRSのための既存のリストを置き換えます。 別のRSクラスタのルートサーバからLISTメッセージを受け取るなら、静かにそれを無視するべきです。
o initializes an empty "informed client" list for its own clients.
o as soon as a BGP/IDRP connection to an RS in the same RS Cluster
is established, transmits an empty LIST message to such an RS.
o 同じRS ClusterのRSとのBGP/IDRP接続が確立されるとすぐに、それ自身のクライアントoのために空の「知識があるクライアント」リストを初期化して、空のLISTメッセージをそのようなRSに送ります。
4.3.3.2 Active State
4.3.3.2 活動的な状態
This state is entered upon expiration of the 'InitiationTimer' or as soon as all configured BGP/IDRP connections to other route servers in the local RS Cluster are established and LIST messages from that route servers are received.
この状態は'InitiationTimer'の満了のときに入られるか、または地方のRS Clusterの他のルートサーバとのすべての構成されたBGP/IDRP接続がそれからの確立しているのとLISTメッセージであるとすぐに、ルートサーバは受け取られています。
In the Active state an RS:
Activeでは、RSを述べてください:
o continues attempts to establish connections with other route
servers in the local and remote clusters;
o 地方の、そして、リモートなクラスタで他のルートサーバで関係を樹立する試みを続けています。
o accepts new BGP/IDRP connections;
o 新しいBGP/IDRP接続を受け入れます。
o transmits a LIST message to an RS in the local cluster as soon
as an BGP/IDRP session with the RS is established and then
whenever the local "informed client" list changes;
o RSとのBGP/IDRPセッションが確立されて、次に、地方が「クライアントに知らせた」ときはいつも、リストが変化するとすぐに、地方のクラスタのRSにLISTメッセージを送ります。
o receives and process BGP/IDRP updates;
o BGP/IDRPアップデートを受けて、処理してください。
o receives and processes "informed client" lists as described
below:
o 受信して、以下で説明されるとして以下を記載しますプロセスが、「クライアントに知らせた」。
a) If a LIST message is received from the route server in
another RS cluster, it should be silently ignored.
a) 別のRSクラスタのルートサーバからLISTメッセージを受け取るなら、静かにそれを無視するべきです。
Haskin Experimental [Page 11] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[11ページ]のRFC1863
b) If a LIST message is received from a route server that
belongs to the same RS Cluster, the differences between
the old and the new list are determined and the old "informed
client" list for that RS is replaced by the list from the new
message. For each client that was in the old list but not in
the new list it is checked whether the server has
an established BGP/IDRP connection to that client and
the client is not in any of the other "informed client"
lists. If both conditions are met, the processing described
for a new client takes place (see 4.3.3.3).
b) 同じRS Clusterに属すルートサーバからLISTメッセージを受け取るなら、古いリストと新しいリストの違いは決定しています、そして、そのRSのための古い「知識があるクライアント」リストを新しいメッセージからリストに取り替えます。 サーバにはそのクライアントには確立したBGP/IDRP接続があるかどうかがチェックされて、古いリストにありましたが、新しいリストにいたというわけではない各クライアントのためにクライアントは他の「知識があるクライアント」リストのいずれにもいません。 見てください。両方の条件が満たされるなら、新しいクライアントのために説明された処理が行われる、(4.3 .3 .3)。
o for each new BGP/IDRP client (including connections established
in Initiation state), decides if that client should become an
"informed client", i.e. whether routing updates are to be sent
to the client or that client has been already taken care by
another RS in the local cluster. The decision process is
described in the next section.
o それぞれの新しいBGP/IDRPクライアント(Initiation状態に確立された接続を含んでいる)のために決める、すなわち、ルーティングアップデートがクライアントに送ることであるまたは地方のクラスタの別のRSが既にそのクライアントに注意したことにかかわらずそのクライアントが「知識があるクライアント」になるべきであるかどうか決めます。 決定プロセスは次のセクションで説明されます。
4.3.3.3 New Client Processing
4.3.3.3 新しいクライアント処理
Whenever an RS acquires a new BGP/IDRP peer it scans through all "informed client" lists in order to determine if this peer has already been receiving routing updates from another RS in the local RS cluster. If the identifying address of the peer is found in one of the list, no routing updates are sent to that peer.
RSが新しいBGP/IDRP同輩を取得するときはいつも、それは、この同輩が地方のRSクラスタの別のRSからルーティングアップデートを既に受けているかどうか決定するためにすべての「知識があるクライアント」リストを通してスキャンされます。 リストの1つで同輩の特定アドレスを見つけるなら、ルーティングアップデートを全くその同輩に送りません。
If the peer's Router Id is not found, the route server initiates a 'DelayTimer' timer for that peer and the decision is postponed until that timer expires. The delay value is calculated as followed:
同輩のRouter Idが見つけられないなら、ルートサーバはその同輩のために'DelayTimer'タイマを開始します、そして、そのタイマが期限が切れるまで、決定は延期されます。 遅れ値は続かれているように計算されます:
the RS determines the relative position of its own "informed
client" list in the linked list of all "informed client" lists.
If such position is expressed with a number, say N, in the 1 to
"maximum number of lists" range, then the delay value is set to
(N-1)*<DelayGranularity>.
RSはすべての「知識があるクライアント」リストの繋がっているリストのそれ自身の「知識があるクライアント」リストの相対的な位置を決定します。 そのような位置が数で言い表されるなら、Nを言ってください、コネ、「最大数のリスト」範囲への1、そして、遅れ値は(N-1)*<DelayGranularity>に設定されます。
Upon expiration of the DelayTimer, the "informed client" lists are scanned once again to see if the corresponding peer has already been receiving routing updates from another RS in the local RS cluster. If the Router Id of the peer is found in one of the lists as a result of receiving a new LIST message, no routing updates are sent to that peer. Otherwise, the peer's Router ID is entered in the "informed client" list that belongs to the RS, the transmission of the updated LIST message is immediately scheduled, and routing updates are sent to the client.
DelayTimerの満了のときに、「知識があるクライアント」リストは、対応する同輩が地方のRSクラスタの別のRSからルーティングアップデートを既に受けているかどうかを見るためにもう一度スキャンされます。 新しいLISTメッセージを受け取ることの結果、リストの1つで同輩のRouter Idを見つけるなら、ルーティングアップデートを全くその同輩に送りません。 さもなければ、RSに属す「知識があるクライアント」リストに同輩のRouter IDに入ります、そして、すぐにアップデートされたLISTメッセージの伝達を予定しています、そして、ルーティングアップデートをクライアントに送ります。
The rational for the delay is to minimize races in the decision as which RS among route servers in the same RSC is going to provide
遅れのために合理的なことはRSCが同じくらいのルートサーバの中のどのRSとして提供するだろうかという決定におけるレースを最小にすることです。
Haskin Experimental [Page 12] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[12ページ]のRFC1863
routing information to a given client. The RS with least number of "informed clients" would have a shortest delay and is the most probable to win the race. This helps to equalize the number of "informed clients" between RSc in a cluster.
与えられたクライアントに情報を発送します。 最少の数の「知識があるクライアント」があるRSは最も少しな遅れを持って、レースに勝つのにおいて最もありえそうです。 これは、ひとかたまりになってRScの間の「知識があるクライアント」の数を均等化するのを助けます。
After an BGP/IDRP peer is placed in the "informed client" list, it is only removed from the list when the BGP/IDRP connection to this peer is lost. While an RS client is in the list it is accurately updated with all routing changes.
「知識があるクライアント」リストにBGP/IDRP同輩を置いた後に、この同輩とのBGP/IDRP接続が迷子になっているときだけ、リストからそれを取り除きます。 RSクライアントがリストにいる間、すべてのルーティング変化で正確にそれをアップデートします。
4.3.3.5 Inter-RS Connection Failure
4.3.3.5 相互RS接続の故障
If a route server loses a routing session with a route server in the same cluster, it must consider taking the responsibilities of route advertisement to the clients that are in the "informed client" list of the remote route server of the failed session.
ルートサーバが同じクラスタのルートサーバとのルーティングセッションを失うなら、それは、失敗したセッションのリモートルートサーバの「知識があるクライアント」リストにいるクライアントにルート広告の責任を取ると考えなければなりません。
For each such client it is checked whether the server has an established BGP/IDRP connection to that client and the client is not in any of the "informed client" lists of active RS. If both conditions are true, the processing described for a new client takes place (see 4.3.3.3).
サーバにはそのクライアントには確立したBGP/IDRP接続があるかどうかがチェックされて、そのような各クライアントのために、クライアントはアクティブなRSの「知識があるクライアント」リストのいずれにもいません。 見てください。両方の状態が本当であるなら、新しいクライアントのために説明された処理が行われる、(4.3 .3 .3)。
After advertisement responsibilities are reconciled the "informed client" list associated with the failed session should be discarded.
広告責任が和解していた後に、失敗したセッションに関連している「知識があるクライアント」リストは捨てられるべきです。
4.3.4 RCID_PATH Attribute
4.3.4 RCID_経路属性
The RCID_PATH is an optional non-transitive attribute that is composed of a sequence of RS Cluster Identifiers (RCID) that identifies the RS Cluster through which routing information carried in the UPDATE message has passed. Type Code of the RCID_PATH attribute is 254. The attribute value field contains one or more RS Cluster Identifiers, each encoded as a 2-octets long field.
RCID_PATHはUPDATEメッセージで運ばれたルーティング情報が終わったRS Clusterを特定するRS Cluster Identifiers(RCID)の系列で構成される任意の非他動詞属性です。 RCID_PATH属性のタイプCodeは254歳です。 属性値分野は1RS Cluster Identifiers、2八重奏のロング・フィールドとしてコード化されたそれぞれを含んでいます。
When a route server propagates a route which has been learned from nother Route Server's UPDATE message, the following is performed with respect to the the RCID_PATH attribute:
ルートサーバが他のRoute ServerのUPDATEメッセージから学習されたルートを伝播するとき、以下はRCID_PATH属性に関して実行されます:
- if the destination of the route is not a route server, the
RCID_PATH Attribute is excluded from the UPDATE message sent to
that client.
- ルートの目的地がルートサーバでないなら、RCID_PATH Attributeはそのクライアントに送られたUPDATEメッセージから除かれます。
- if the destination of the route is another route server that is
located in the advertising server's own RS cluster, the
RCID_PATH attribute is sent unmodified.
- ルートの目的地が広告サーバの自身のRSクラスタに位置している別のルートサーバであるなら、変更されていなくRCID_PATH属性を送ります。
Haskin Experimental [Page 13] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[13ページ]のRFC1863
- if the destination of the route is a route server in a different
RS cluster, the advertising route server shall verify that the
RCID of the destination speaker's cluster is not present in
the RCID_PATH attribute associated with route. If it does,
the route shall not be advertised and an event indicating
that a route loop was detected should be logged, otherwise
the advertising router shall prepend its own RCID to the RCID
sequence in the RCID_PATH attribute (put it in the leftmost
position).
- ルートの目的地が異なったRSクラスタのルートサーバであるなら、広告ルートサーバは、目的地スピーカーのクラスタのRCIDがルートに関連しているRCID_PATH属性で存在していないことを確かめるものとします。 そうするなら、ルートの広告を出さないものとします。ルート輪が検出されたのを示すのはそうするべきであるイベントが登録されて、さもなければ、広告ルータはRCID_PATH属性(一番左位置にそれを入れる)におけるRCID系列へのprependのそれ自身のRCIDの広告を出すでしょう。
When a route server propagates a route which has been learned from a border router to another route server then:
ルートサーバがその時境界ルータから別のルートサーバまで学習されたルートを伝播するとき:
- if the destination of the route is a route server that is
located in the advertising router's own RS cluster, an empty
RCID_PATH attribute shall be included in the UPDATE message
(an empty RCID_PATH attribute is one whose length field contains
the value zero).
- ルートの目的地が広告ルータの自身のRSクラスタに位置しているルートサーバであるなら、空のRCID_PATH属性はUPDATEメッセージに含まれているものとします(空のRCID_PATH属性は長さの分野が値ゼロを含むものです)。
- if the destination of the route is a route server in a different
RS cluster, the advertising route server shall include its own
RCID in the RCID_PATH attribute. In this case, the RCID of
advertising route server will be the only entry in the RCID_PATH
attribute.
- ルートの目的地が異なったRSクラスタのルートサーバであるなら、広告ルートサーバはRCID_PATH属性にそれ自身のRCIDを含んでいるものとします。 この場合、広告ルートサーバのRCIDはRCID_PATH属性で唯一のエントリーになるでしょう。
4.3.5 NOTIFICATION Error Codes
4.3.5 通知エラーコード
In addition to the error codes defined in the BGP-4/IDRP specification, the following error can be indicated in a NOTIFICATION message that is sent by a route server:
BGP-4/IDRP仕様に基づき定義されたエラーコードに加えて、ルートサーバによって送られるNOTIFICATIONメッセージで以下の誤りを示すことができます:
255 LIST Message Error
255 リストメッセージ誤り
The following error subcodes can be associated with the LIST Message Error:
以下の誤り部分符号をLIST Message Errorに関連づけることができます:
1 - Bad Address. This subcode indicates that a Client Identifying
Address in the received LIST message does not represent
a valid network layer address of a router interface.
1--悪いアドレス。 この部分符号は、受信されたLISTメッセージのClient Identifying Addressがルータインタフェースの有効なネットワーク層アドレスを表さないのを示します。
The following additional UPDATE error subcodes are also defined:
また、以下の追加UPDATE誤り部分符号は定義されます:
255 - Invalid ADVERTISER Attribute. This subcode indicates that
a value of the ADVERTISER Attribute does not represent
a valid network layer address of a router interface.
255--無効の広告主属性。 この部分符号は、ADVERTISER Attributeの値がルータインタフェースの有効なネットワーク層アドレスを表さないのを示します。
Haskin Experimental [Page 14] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[14ページ]のRFC1863
4.3.7 Timers
4.3.7 タイマ
The InitiationTimer value of 5 minutes is suggested.
5分のInitiationTimer値は示されます。
In order to avoid route flaps during an RS switch-over, a value of DelayGranularity should be such so the maximum possible value of the DelayTimer (see 4.3.3.3) combined with the Hold Time of inter-RS connections would be shorter than two-third of the smallest Hold Time interval of all BGP/IDRP connections between the route servers and their clients (including RSs in other clusters). So in a cluster with three RSs and the respective Hold Times of 30 and 90 seconds the DelayGranularity of 15 seconds would be a recommended value.
DelayGranularityの値は、オーバーRSスイッチの間、ルートフラップを避ける可能な最大が評価するDelayTimerのそのようなそうであるべきです。(.3が)相互RS接続のHold Timeに結合した.3がルートサーバのすべてのBGP/IDRP接続の最も小さいHold Time間隔と彼らのクライアントの2/3より短いのを(他のクラスタにRSsを含んでいて)4.3に確実にしてください。 あまりにひとかたまりになって30と90秒の3RSsとそれぞれのHoldタイムズと共に、15秒のDelayGranularityは推奨値でしょう。
For the same reason it is recommended that the Hold Time of BGP/IDRP connections between route servers in the same cluster is set to one- third of the smallest Hold Time of all BGP/IDRP connections between the route servers and their clients (including RSs in other clusters). So, if the smallest Hold Time of BGP/IDRP sessions with clients is 90 seconds, the recommended value of the Hold Time of BGP/IDRP connections between route servers in that cluster would be 30 seconds.
同じ理由で、同じクラスタのルートサーバの間のBGP/IDRP関係のHold Timeがルートサーバと彼らのクライアントとのすべてのBGP/IDRP関係の最も小さいHold Timeの1/3へのセット(他のクラスタにRSsを含んでいて)であることはお勧めです。 それで、クライアントとのBGP/IDRPセッションの最も小さいHold Timeが90秒であるなら、そのクラスタのルートサーバの間のBGP/IDRP関係のHold Timeの推奨値は30秒でしょう。
5. Route Server Discovery
5. ルートサーバ発見
This document does not propose any mechanism for the dynamic RS discovery by RS clients or/and by other route servers. It is assumed that at minimum a manual configuration will be provided in participating routers to achieve the needed connectivity.
このドキュメントはダイナミックなRS発見のためにRSクライアントか/と他のルートサーバでどんなメカニズムも提案しません。 最小限で、手動の構成が必要な接続性を達成するために参加ルータに提供されると思われます。
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this document.
本書では安全保障問題について議論しません。
8. Acknowledgment
8. 承認
Some design concepts presented in this paper benefited from discussions with Tony Li (cisco Systems).
この論文に提示されたいくつかの設計思想がトニー・李(コクチマスSystems)との議論の利益を得ました。
Author likes to thank John Krawczyk (Bay Networks) and Susan Harris (Merit) for their review and valuable comments.
同類を書いて、彼らのレビューと貴重なコメントについてジョンKrawczyk(ベイネットワークス)とスーザン・ハリス(長所)に感謝してください。
Also, author would like to thank Yakov Rekhter (IBM) for the review of the earlier version of this document and constructive comments.
また、作者はこのドキュメントと建設的なコメントの以前のバージョンのレビューについてヤコフRekhter(IBM)に感謝したがっています。
Special thanks to Ray Chang (Bay Networks) whose experience in implementing the concepts presented in this document helped to refine the route server design.
概念が実装することの経験を提示したレイ・チャン(ベイネットワークス)への特別な感謝は、ルートサーバデザインを洗練するのを本書では助けました。
Haskin Experimental [Page 15] RFC 1863 A BGP/IDRP Route Server October 1995
BGP/IDRPルートサーバ1995年10月あたりハスキンExperimental[15ページ]のRFC1863
9. References
9. 参照
[BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp.,
cisco Systems, March 1995.
[BGP4] Rekhter、Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771、T.J.ワトソン研究所、IBM社、コクチマスSystems(1995年3月)。
[IDRP] Rekhter, Y., and P. Traina, "IDRP for IPv6", Work In Progress.
[IDRP] Rekhter、Y.とP.Traina、「IPv6"、進行中の仕事のためのIDRP。」
10. Author's Address
10. 作者のアドレス
Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821
ビルリカ、ドミトリーハスキンベイネットワークスInc.2の連邦政府の通りMA 01821
EMail: dhaskin@baynetworks.com
メール: dhaskin@baynetworks.com
Haskin Experimental [Page 16]
ハスキンExperimentalです。[16ページ]
一覧
スポンサーリンク
