Internet Draft Internet Engineering Task Force C-Y Lee INTERNET DRAFT A Celer November 2000 Distributed Constraints Exchangers <draft-lee-mpls-te-exchange-00.txt> Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The current link state routing protocols flood link states to all routers so that routers have the information required to compute the shortest paths to route packets on a hop by hop basis. However, for the purpose of establishing MPLS paths, constraint paths are only required at certain nodes, for instance, at the node where path setup is triggered or at the head-end of a loosely routed segment that crosses a network (or area) boundary. In addition, it not possible to have all required constraints present in all nodes in a network, nor is it always feasible for nodes setting up paths to compute the constraint paths themselves, a notable example is when a path traverses network or area boundary. These reasons motivate a solution using distributed route exchangers, to collect constraint information and exchange it with other route exchangers. Route exchangers store traffic engineering link states and other types of constraint information and compute the explicit routes required by routers establishing paths. Hence, constraint information need only Expires June 2001 [Page 1] Internet Draft Distributed Constraints Exchangers November 2000 be distributed to the subset of nodes which help compute constraint paths in the network. 1. Introduction The current link state routing protocols flood link states to all routers so that routers have the information required to compute the shortest paths to route packets on a hop by hop basis. However, for the purpose of establishing MPLS paths, constraint paths are only required at certain nodes, for instance, at the node where path setup is triggered or at the head-end of a loosely routed segment that crosses a network (or area) boundary. In addition, it not possible to have all required constraints present in all nodes in a network, nor is it always feasible for nodes setting up paths to compute the constraint paths themselves. In particular, summarized inter-area routes do not provide sufficient information for a node to compute the constraint path required across areas. In this case, the node can request the transit area border router (functioning as route exchangers as well) to compute the explicitly routed path on its behalf. The area border router may recurse this request if the destination is in yet another area. Further, it is not always feasible to compute constraint paths independently at each node, because some constraint information must be coordinated at a centralized server. Therefore, some constraint paths must be computed at a constraint route server. To provide redundancy and load balancing, a number of these servers are distributed in the network, and they can be co-located with the route exchangers to facilitate constraint path computation. The above reasons provides the motivation for a solution using distributed route exchangers, to collect traffic engineering link states and exchange it with other route exchangers. Route exchangers store traffic engineering link states and other types of constraint information and compute the explicit routes required by routers establishing paths. It should be noted that the total number of link states received by a route exchanger is no more than, and in general less than the total number of link states received by a router if the link states are flooded instead. 2. Overview The memo describes a solution using distributed route exchangers to collect traffic engineering link states and exchange it with other route exchangers. Route exchangers store traffic engineering link states and compute the explicit routes requested by routers (e.g. Expires June 2001 [Page 2] Internet Draft Distributed Constraints Exchangers November 2000 edge routers or nodes setting up backup segments) establishing paths. Note that route exchangers may be co-located on edge or border routers. The rest of this memo describes how OSPF can be modified for this purpose. IS-IS can be extended in a similar way. Route exchangers or traffic engineering exchangers (TE-Xs) advertise their capability via router link state advertisements (router-LSAs), allowing OSPF routers in an area to discover all the TE-Xs in the area. An OSPF router sends its traffic engineering link state advertisements (te-LSAs) directly to the nearest TE-X, instead of flooding them to all interfaces. A TE-X disseminates link states it receives from nearby OSPF routers, to other TE-Xs in an area, via a designated TE-X. TE-Xs in an area send Hello messages to each other and elect a designated and backup designated TE-X (DR TE-X, BDR TE-X, respectively), in the same manner as OSPF DR and BDR are elected. The DR TE-X peers with all other TE-Xs in an area and distributes the traffic engineering link states it learnt from a TE-X to other TE-X. The BDR TE-X peers with all other TE-Xs in an area and but do not distribute the traffic engineering link states it learnt from a TE-X to other TE-X. The backup designated TE-X assumes the role of the designated TE-X when the designated TE-X goes down. The reason for having the BDR TE-X peers (which involves TE LSDB synchronization) with other TE-Xs is to reduce the time it takes to "switch" to the BDR TE-X when a DR TE-X becomes unreachable. Otherwise the BDR TE-X has to synchronize its TE LSDB with all other TE-Xs before it can assume the role of DR TE-X. To setup an explicit path, if a router is a TE-X, it has the traffic engineering link state database, and is able to compute the explicit path. If the router is not a TE-X, it : a) discovers TE-Xs via normal router-LSAs as described above. b) queries the nearest TE-X for a route satisfying the constraints specified. The TE-X should return an explicit set of routes (the Explicit Route Object (ERO), as specified in MPLS). If the destination is in another area, the router setting up the path should request the route from the transit ABR TE-X to the other area. The ABR TE-X should return either a complete explicit set of routes all the way to the destination, or it may consist of loose segments for paths in other areas. The exact semantics of the query and response message is out of scope of this memo. An area border router (ABR) should be a TE-X in each area it is attached to by default. This facilitates TE inter-area link states summarization, dissemination as well as TE path setup. At this point it is not clear whether it is necessary to mandate ABRs be TE-Xs, although as mentioned there are advantages in having ABRs be TE-Xs. Expires June 2001 [Page 3] Internet Draft Distributed Constraints Exchangers November 2000 An ABR summarizes the TE link states, i.e te-summary-LSAs in an area and sends them to the DR and BDR TE-Xs in other areas it is attached to. If the ABR is not a DR or BDR TE-Xs in an area, it receives te- summary-LSAs from other areas via the DR in that area. 3. Advantages and Disadvantages 3.1 Advantages This solution allows link state routing protocols such as OSPF to be extended to distribute constraint resource information, for the purpose of establishing explicit paths, using less total network and routers resources (in terms of bandwidth, processing, and routing information storage) than if the constraint link states are flooded instead. The extension is well suited for constraint route distribution in an optical network where it is not always feasible to flood large amount of constraint information and where the port density is high. In particular, it improves the efficiency of inter-area path setup because it enables a node to determine if an inter-area path is able to meet the constraints specified and obtain the complete explicit path if needed, before the inter-area path setup is attempted. Further, constraint link state database convergence time is also reduced since constraint link states need not be: i) processed nor acknowledged hop by hop. ii) "damped" to reduce the disruption to the network caused by flooding link states. If each router in a network originates l number of LSAs and flood the l LSAs on p number of ports, a router in a network could potentially receive up to n*l*p number of LSAs, in a network with n nodes. Therefore, the total number of LSAs flooded and processed in the network is of order n squared (and could potentially be close to n*n*l*p). If each router in a network originates l number of te-LSAs and send the l LSAs directly to the TE-X, only the TE-Xs receives n*l number of LSAs. Note that l LSAs are not flooded on all ports of the router. In this case, the total number of LSAs processed in the network is close to x*n*l, where x is the number of TE-Xs in the network. Since x can be a lot smaller than n, this proposal reduces the total te-LSAs flooded, processed and stored in a network, or in other words the total amount of network and node resources required for te-LSAs, is reduced from O(n squared) to O(n), in a network with n nodes. Clearly, the total number of link states received by a TE-X is no more than, and in general significantly less than the total number of te-LSAs received by a router if the te-LSAs are flooded instead. The te-LSAs are not flooded like normal LSAs used to calculate the "shortest path". Hence a router only sends out one copy of its te- LSAses and the te-LSAs are forwarded directly (on fast path) to the Expires June 2001 [Page 4] Internet Draft Distributed Constraints Exchangers November 2000 nearest TE-X, without incurring processing delay including acknowledgment on every hop, which occurs when link states are flooded. Similarly, a TE-X sends te-LSAs directly to other TE-Xs via the peering with other TE-Xs. Consequently, the time for the traffic engineering link state database (TE LSDB) to converge within the routing domain is reduced. Routers not involved in acquiring explicit paths (e.g for the purpose of initiating the establishment of explicit paths or to obtain the explicit hops in the loose segment of a loose source route) are not burdened with processing and storing additional te-LSAs (in addition to normal link states) that they do not need. Inter-area route summarization is done by ABRs which by default (for reasons mentioned before) are TE-Xs, and the ABRs send the te- summary-LSA directly to the DR and BDR TE-Xs in other areas, instead of flooding them in the routing domain. Hence the same advantages described in the previous paragraph applies here. An important advantage for inter-area path computation is the feasibility for an ABR to provide explicit route (which have sufficient resources or meeting the constraints specified) for another area. For instance node A in area 1 wants to setup a path to node B, which is in the backbone. The ABR serving the area where node A is located is able to provide the route meeting the constraints required by A, all the way to B, either as a complete explicit route or it may consist of a loose source route portion for the path between the ABR and B. In either case, this improves inter-area path setup and reduces the probability of (a) path setup failures or crankbacks (b) available resources not being used, due to insufficient information provided by route summarization. Routers which support constraint or traffic engineering path setup (called OSPF-TE in this memo) need to have the functions specified in "Changes to OSPF routers originating te-LSAs" of this memo. However it is feasible to do only a software upgrade on existing Label Switching Routers (LSRs) with OSPF-TE support since there are very little processing and storage impact on the routers, compared to the case where all routers in a domain have to process te-LSAs. The more heavy weight processing and storage requirement is at the TE-X, where the processing and storing of large number of te-LSAs and TE routes computation is performed. Large number of constraint link states that are not dynamic in nature can be distributed to TE-Xs during TE database initialization and downloading and used by TE-Xs for constraint route computation later. Constraint information not specific to particular links or or that cannot be downloaded to every node or that must be configured in a coordinated manner eg on a server can be distributed to TE-Xs by a server which is functioning as a TE-X. This allows a TE-X to take Expires June 2001 [Page 5] Internet Draft Distributed Constraints Exchangers November 2000 into account such constraints during constraint path computation. This proposal avoids the single point of failure and the performance bottleneck inherent in solutions based on a centralized server, by disseminating constraint information to distributed TE-Xs. 3.2 Disadvantages Routers which do not have the constraint information have to obtain constraint paths from TE-Xs. One question is how much delay this adds to the process of establishing paths. In general, since the bulk of time in establishing paths is in the propagation and processing of path setup messages (including path computation) the latency (order of msec) to obtain a path from a nearby node is not significant. In the case where constraint routes are required for on-demand path recovery or on-demand repair of primary paths/segments of the paths, the time required for restoration is largely dominated by the time it takes for routes to converge after a link failure. (Note: smaller than 50msec recovery requires protection switching of pre-established backup paths or segments). Again, the path query and response latency is not significant relative to the route convergence time. It is worth noting that even though constraint information states are accessible locally at every node if constraint information are flooded to every node, the actual path setup time may be longer than if the constraint route is obtained from a TE-X. The reason is the local constraint information may not be up to date. To reduce the disruption cause by the flooding of constraint information, constraint link state changes cannot simply be flooded whenever there is a change. It needs need to be "damped" or suppressed for a pre- defined period of time. Since frequent flooding may cripple a network, especially in the case of a densely meshed network, the tendency is to delay flooding for longer periods. The use of stale information may cause path setup failure which would add significant delay in the actual path setup time or it may prevent available resources from being utilized at all. 4. Terminology In this memo OSPF routers refers to non TE-X. OSPF routers supporting the TE-LS distribution in this memo is referred to as OSPF-TE routers. The normal Link State Database is referred to as LSDB and the TE Link State Database is referred to as LSDB-TE. 5. Assumptions The routers in the network are assumed to be connected (e.g via a control channel) and can be reached via shortest path routes computed Expires June 2001 [Page 6] Internet Draft Distributed Constraints Exchangers November 2000 using normal LSAs flooded by OSPF. To be able to discover TE resources (eg links, bandwidth) to another router X, a router Y must already have connectivity to router X, either via an existing link or a control channel setup for control messages (for e.g MPLS signalling, OSPF control messages) between X and Y. Note that if there are multiple parallel links between two routers, only one control channel is required to allow the routers to learn about each other's resources. If X is reachable (but not directly), it is also possible for Y to learn (through the TE-X) about the "on-demand" links that could potentially be used to reach X directly, and for Y to advertise (again via TE-X) the potential "on-demand" links that could connect it directly or in "one hop" to X or other networks, and vice-versa. This may be useful in the case where Y may have connectivity to X e.g via Z as shown below, but not a direct link to X yet and may setup "on-demand" circuits to X when there is a need for it. X-------Z * | * | "on-demand" * | link * | * Y 6. Overview of extensions to OSPF The following sections describe the extensions required in OSPF for nodes (i) originating te-LSAs and (ii) functioning as constraint route or TE exchangers. Both nodes originating te-LSAs only and nodes functioning as TE-Xs must be able to discover the addresses of TE-Xs in an area. Only nodes functioning as TE-Xs need to advertise themselves with the TE option bit in the Option field of the router-LSA. The te-LSAs originated by nodes have the same format as te-LSAs (TLVs and sub-TLVs) described in [OSPF-KY] and [OMPLS], and the LSA is of type 12 (TE) instead of opaque type 10 (scope area). Instead of flooding these te-LSAs out of every adjancencies, an OSPF node sends one copy of the te-LSAs directly to the nearest TE-X. An OSPF node functioning as a TE-X must be able to receive the te-LSAs and send them to the DR and BDR TE-Xs in the area. A DR TE-X must send the te-LSAs to other TE-Xs in the area. 6.1. Changes to OSPF routers originating te-LSAs Expires June 2001 [Page 7] Internet Draft Distributed Constraints Exchangers November 2000 OSPF-TE routers (non TE-Xs) originating te-LSAs send Link State Update (LSU) directly to the nearest TE-X instead of flooding them out. Te-LSAs are not received by other OSPF routers unless these routers are TE-Xs. OSPF-TE routers do not receive te-LSAs originated by other OSPF routers, nor do they send te-LSAs to other other OSPF routers (unless they are TE-Xs) or exchange te-LSAs with other OSPF routers. An OSPF-TE should maintain a list of TE-Xs in an area. Each entry in the list should contain the distance to the TE-X. How this is accomplished is implementation dependent. One way of implementing this is to compute the shortest path to a router which is a TE-X (as indicated in the router-LSA), during SPF computation and either store the distance to the TE-X in the "list of TE-Xs" data structure or as a router entry in the OSPF routing table. The Router ID of TE-X should be a unique IP address identifying the router in the Autonomous System and ideally should not be an interface address, but an address not assigned to any interfaces. It may be an address assigned to a "loopback" or dummy interface. When an OSPF-TE router first comes up, it establishes adjacencies with its neighbor(s). Once adjacencies are established (Section 7 of [OSPF]), an OSPF-TE router determines the nearest TE-Xs. The OSPF-TE goes through its list of TE-Xs, and caches up to two TE-Xs (the primary TE-X and a backup TE-X), as described in "Determining nearest TE Exchanges". TE-X capability is advertised in Router-LSA, as described in the Section "Advertising TE Exchanges". 6.1.1 Originating te-LSAs At initialization, prior to sending the te-LSAs the OSPF-TE router should send a TE Database summary list and wait for acknowledgement from the TE-X. The details of this procedure is described in "Sending Link State Update te-LSAs". The OSPF-TE router then proceeds to originate te-LSA describing its connectivities or links and the constraints associated with these connectivities and send these te-LSAs to the nearest TE-X. The te- LSAs are defined in [OSPF-KY] with the following format : +-----------------------+ | Standard LSA Header | +-----------------------+ | Type, Length, Value | +-----------------------+ Expires June 2001 [Page 8] Internet Draft Distributed Constraints Exchangers November 2000 There are 2 types currently defined: 1) Router TLV - describes the always reachable address of the router 2) Link TLV - describes a single link. The following sub-TLVs of the Link TLV - Link type, Link ID, local/remote interface IP address describes the link and the maximum bandwidth, maximum reservable bandwidth, resource class, describes the constraints of that link. Additional sub-TLVs are defined in "Additional sub-TLVs in te-LSA" and [OMPLS] and these te-LSAs can be distributed using the mechanisms described in this proposal. If the TE-X does not acknowledge the te-LSA sent, the OSPF-TE router must attempt to retransmit the te-LSA to the backup TE-X. 6.1.1.1 Sending Link State Update te-LSAs OSPF-TE routers sends te-LSAs directly to the nearest TE-X. If an OSPF router do not receive a Link State Acknowledge for a te-LSA sent to a particular TE-X after a timeout period, it sends the te-LSA to the next nearest TE-X and reinvoke the "Determining nearest TE-X" mechanism to find out the current serving TE-Xs. Initially, a Database Summary List is sent and the OSPF-TE expects to receive Link State Request of the te-LSAs originated by this OSPF-TE that the TE-X wants to update in its database. The OSPF-TE sends the te-LSAs to the TE-X as requested in the Link state Request message. The difference with the OSPF database synchronization is OSPF-TEs do not request te-LSAs from the TE-X in this proposal. An OSPF-TE router do not initiate adjacency establishment nor maintain adjacency or exchange hellos with a TE-X. An OSPF-TE router is able to find out the serving TE Exchange via router-LSAs (See "Determining nearest TE Exchanges"). 6.1.2 Discovering TE Exchanges OSPF-TE routers discover TE Exchanges via normal Router-LSA flooding, as described in "Advertising the TE Exchange" . When an OSPF-TE router receives a new router-LSA with "TE-X" capability bit on, it stores the TE-X IP address in the TE-X data structure. In addition, once the Dijkstra computation of routes to all destinations in the network is performed, the OSPF-TE should store the cost to each TE-X in an area, in the TE-X data structure as well. Each OSPF-TE maintains a TE-X list for every area. 6.1.3 Determining the nearest TE Exchanges Expires June 2001 [Page 9] Internet Draft Distributed Constraints Exchangers November 2000 If the edge router is a TE-X, then the nearest TE-X is itself, otherwise, the "nearest" TE-X is the TE-X with the smallest link costs from the router. The link costs to TE-Xs is determined from the previous section. Once an OSPF-TE has received the routing information in the domain, it goes through its list of TE exchanges, starting from the nearest TE-X, to find out which of the TE-Xs agree to serve the OSPF-TE. The route to a TE-X is determined from the routing table calculation, in Section 16.1 of [OSPF]. The OSPF-TE sends a probe message to each of the TE-X in the list, until two TE-Xs agrees to serve the OSPF-TE, by acknowledging the probe message. The nearest TE-X acknowledging the probe message is the primary TE-X, and the next nearest TE-X acknowledging the probe is the backup TE-X. If two TE-X are of the same distance away, the one with the smaller difference in address value as the Router ID of the OSPF-TE, is chosen as the primary TE-X and the other as the backup TE-X. [Alternatively, the TE-X which acknowledges the probe message first is selected as the primary TE-X] If only one TE-X responds to the probe messages, then the OSPF-TE is served by only one TE-X, and the OSPF-TE should generate an alert message to the router management system. 6.2 TE Exchange TE-Xs must participate in normal OSPF route distribution, although they may not necessarily be participating in path setup or be able to "label switch", for instance a TE-X may be a leaf of the network, setup to function solely as a route exchange. 6.2.1 Advertising the TE-X A TE-X must advertise its capability in the Router LSA Option field as shown in the Appendix. A X-bit in the Options field is defined for this purpose. 6.2.2 TE Exchange Peering At initialization, a TE-X behaves like a normal OSPF router, creating adjacencies with its neighbor(s) to exchange normal (non TE) routing information. Once a TE-X has established adjacencies and downloaded the domain (non TE) link state database (as defined in the RFC2328), the TE-X start to establish adjacencies or peering with other TE-Xs in the area, that it learnt from normal (non-TE) router-LSAs (and stored in the list of TE-Xs). The peering with other TE-Xs is established similar to the creation of adjacencies with OSPF neighbor(s). The TE-X sends to each TE-X in Expires June 2001 [Page 10] Internet Draft Distributed Constraints Exchangers November 2000 the area Hello or Keep-Alive (the latter term is used to differentiate from OSPF Hello) messages. Once the DR TE-X of the area is discovered via the Keep-Alive message, the TE-X attempts to peer with the DR TE-X. The TE-X then proceeds to exchange the te-LSAs, in the same way as Database synchronization and Exchange of normal LSAs, until it has obtain the full te-LSA of the routing domain. Designated TE-X (DR TE-X) and backup Designated TE-X (BDR TE-X) in an area are elected the same way as OSPF DR and BDR. The DR TE-X is responsible to peer with other TE-Xs in an area. 6.2.2.1 Relaying te-LSAs to other TE-Xs A TE-X sends te-LSAs to the DR TE-X and BDR TE-X, which in turn sends the te-LSAs to other TE-Xs. All te-LSAs sent must be acknowledged in the same way as normal LSAs are acknowledged. All TE-Xs maintain a consistent TE LSDB of the routing area by synchronzing and exchanging te-LSAs via the peering with the DR and BDR TE-Xs. [Note: a TE-X does not peer with other (non TE-X) OSPF-TEs.] 6.2.3 TE-X availability An area of a network should have at least three distributed TE-Xs such that if one TE-X fail, a primary and secondary TE-X is always available to serve all the OSPF-TEs, assuming the network is not partitioned. TE-Xs should be configured in a distributed manner in a network such that if a primary or secondary TE-X is down or not reachable, the next closest TE-Xs can be used instead. Preferably, TE-Xs should be positioned close to edge routers or be routers that are connected to a large number of edge routers. If the TE-Xs are well distributed in the network and provisioned in regions which can easily lose connectivity to the rest of the network, for instance if the link R2-R4 is down and the network is partitioned, the edge routers R1 and R6 are still able to reach the TE-X at R2. Similarly R5 and R7 is able to use the TE-X at R4. R1---R2---R4--R5 | | | | | | R6 R7 Expires June 2001 [Page 11] Internet Draft Distributed Constraints Exchangers November 2000 A region of the network may partition from the rest of the network if there are not suffficient redundant connectivity to the rest of the network. If no TE-X has been provisioned in a partitioned region (for e.g. TE-Xs have not been appropriately distributed to compensate for the region with a high risk of being partitioned from the network because the region is deemed too small to have a TE-X)), then edge routers in that partitioned region will not have TE-Xs to serve them. In this case, (where there are no available TE-Xs in the rare event that the network partitions) edge routers should advertise themselves as TE-Xs to enable them to receive te-LSAs. This procedure is added as a precaution in case not enough redundancy is designed in the network. It should be noted that in a well designed network, network partitioning should be a relatively rare occurence. Hence it is expected that the situation where edge routers have no available TE-Xs may rarely occur when a smaller region of the network partitions. Since the total number of te-LSAs in that partitioned region of the network should be relatively smaller, the total number of te-LSAs that must be exchanged between edge routers should be relatively smaller as well, allowing normal routers to handle the additional LSA storage and processing. 6.3 Updating resources at OSPF-TE and TE-X Once the OSPF-TE router has setup a path (the router may be functioning as a Label Switched Router, LSR), it should update the TE-X of its currently available resources. The OSPF-TE should originate new te-LSAs reflecting its available resources. The TE-X should distribute these new te-LSAs to its peering TE-Xs. It should be noted that all TE-Xs must have consistent TE-LSDBs, but OSPF-TEs do not maintain TE-LSDBs. When the connectivity associated with constraints or TE of an OSPF-TE router changes (eg due to interface or link failure), the OSPF-TE must originate new te-LSAs reflecting the connectivity and currently available resources. A TE-X must replace older te-LSAs from its TE-LSDB with newer te-LSAs from an OSPF-TE. Other peering TE-Xs should do the same when they receive the new te-LSAs. This ensures the TE-LSDB in the routing area is consistently up to date. There may be instances where during a path setup LSP1, a TE-X, using the existing TE-LSDB, may compute another path LSP2, which traverses some of the links of LSP1. However there may not be enough resources left for LSP2 along those links after LSP1 is established. The necessity of having absolute up to date information should be examined carefully. Nevertheless, the timely distribution of available resources can be improved by leveraging on the TE-X knowledge of resources that will be allocated, and distributing the knowledge to other TE-Xs. A TE-X knows how much resources will be Expires June 2001 [Page 12] Internet Draft Distributed Constraints Exchangers November 2000 allocated on routers when it responds to constraint route queries or requests. The need for this optimization is currently being examined. 6.4 Loose source routing A Label Switching Router (LSR) may obtain explicit route from a TE-X if it is provided with Loose Source Route in a path setup signalling. It is expected Loose Source Route will be mainly used in inter-area path setup (where the explicit route in another area is not known). However, as described earlier and in the next sections, an TE-X functioning as an ABR as well is able to provide the complete explicit route for an inter-area path. Hence a node may specify the complete explicit route in the path setup signalling message instead of having to use a Loose Source Route for the inter-area path. 6.5 Area Border Routers (ABRs) A TE-ABR in an area should be TE-Xs in all areas that it is attached to allow the ABR to receive te-LSAs in all the areas it is attached to and to exchange summary te-LSAs with peering TE-Xs in other areas. ABR TE-Xs inject te-summary-LSAs into other areas. The definition of network summary te-LSA is not within the scope of this memo. The next section describes how te-summary-LSAs are distributed. A node setting up an inter-area path should request the constraint path from the transit ABR TE-X. The ABR TE-X should return either a complete explicit path or an explicit path for the area the node resides, concatenated with loose segments of paths in other areas. An ABR TE-X may choose to cache the explicit routes in the loose segment for later use or "expand" the loose segment during path setup. 6.5.1 TE route summarization An ABRs summarizes te-LSAs in an area it is attached to and send the te-summary-LSAs directly to DR and BDR in other areas it is attached. An ABR which is also the DR TE-X in an area summarizes the te-LSAs in the area and relays them to DR and BDR TE-Xs in other areas it is attached to. A DR TE-X in an area relays te-summary-LSAs for other areas (from other ABRs) to all other TE-Xs in the area A BDR TE-X, in an area do not relay te-LSAs or te-summary-LSAs that it receives to any other TE-Xs in the area. 7.0 Acknowledgment The authors would like to thank Radia Perlman, Neil Gammage, Darek Skalecki, Don Fedyk, Jim Boyle, Sudhakar Ganti, Dave Katz, Loa Andersson, Tony Przygienda for their helpful comments and Expires June 2001 [Page 13] Internet Draft Distributed Constraints Exchangers November 2000 suggestions. Expires June 2001 [Page 14] Internet Draft Distributed Constraints Exchangers November 2000 Appendix A - Packet Format A.1 Options Field in LSA Header +------------------------------------+ | X | O | DC | EA | N/P | MC | E | * | +------------------------------------+ The Options Field^M E-bit^M This bit describes the way AS-external-LSAs are flooded, as^M described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].^M MC-bit^M This bit describes whether IP multicast datagrams are forwarded^M according to the specifications in [MOSPF].^M N/P-bit^M This bit describes the handling of Type-7 LSAs, as specified in^M [NSSA].^M DC-bit^M This bit describes the router's handling of demand circuits, as^M specified in [DEMD].^M EA-bit^M This bit describes the router's willingness to receive and^M forward External-Attributes-LSAs, as specified in [EAL].^M O-bit^M This bit describes the router's willingness to receive and^M forward Opaque-LSAs as specified in [rfc2370].^M X-bit This bit describes the router willingness to be a TE Exchanger to receive and distribute constraint routes as well as compute and provide constraint paths or explicit routes when queried A.2 LSA Header As described in [OSPF-KY], the te-LSA starts with the standard LSA header, the Type is of value 12 (not flooded in an area like Type 10 Opaque LSA): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Expires June 2001 [Page 15] Internet Draft Distributed Constraints Exchangers November 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Reserved | Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The rest of the TLVs and sub-TLVs in the te-LSA are as described in [OSPF-KY]. Expires June 2001 [Page 16] Internet Draft Distributed Constraints Exchangers November 2000 References The following references are available at http://www.oiforum.org [OIF-CONSRAINT] oif2000.109.0, "Some Routing Constraints" Monica Lazer, John Strand The following references are available at http://www.ietf.org [RFC2328] RFC 2328 OSPF Version 2. J. Moy. April 1998. [TE_OPT] draft-awduche-mpls-te-optical-01.txt [UNIQUE-CONST] draft-chiu-strand-unique-OLCP-00.txt [QOS_RTG] draft-ash-te-qos-routing-01.txt [LIGHTPATH] draft-chaudhuri-ip-olxc-control-00.txt [RFC2370] The OSPF Opaque LSA Option [OSPF-KY] draft-katz-yeung-ospf-traffic-01.txt [OMPLS] draft-kompella-ospf-ompls-extensions-00.txt [CR-LDP] draft-ietf-mpls-crldp-03.txt [OSPF_FLD] draft-pillay-esnault-ospf-flooding-01.txt [RFC1793] RFC 1793 Extending OSPF to Support Demand Circuits. J. Moy. April 1995. Authors' Information Cheng-Yin Lee leecy@nortelnetworks.com Alicja Celer aceler@nortelnetworks.com Expires June 2001 [Page 17]