SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Riverstone Networks (RSTN) -- Ignore unavailable to you. Want to Upgrade?


To: ahhaha who wrote (82)7/22/2001 7:40:37 PM
From: ahhaha  Read Replies (1) | Respond to of 290
 
LSP HIERARCHY

LSP hierarchy is the notion that LSPs can be nested inside other LSPs, giving rise to a hierarchy of LSPs. This is achieved by considering an LSP as a link in the IS-IS or OSPF link state database. This simple notion offers a solution to issues 1 and 2 above.

MPLS LSPs that enter the optical transport domain at the same node and leave the domain at the same node may be aggregated and tunneled within a single optical LSP. This aggregation helps to conserve the number of lambdas used by the MPLS domain.

LSP hierarchy also helps deal with the discrete nature of optical bandwidth. When an optical LSP is set up, it gets a discrete bandwidth (say 2.488 Gb/s). However, when this optical LSP is treated as a link, that link’s bandwidth need no longer be discrete. A 100 Mb/s MPLS LSP that crosses the optical transport domain can be tunneled through the optical LSP, leaving 2.388 Gb/s for other MPLS LSPs. Allocating an entire 2.488 Gb/s for every MPLS LSP that crosses the optical domain would be impractical. A natural hierarchy exists that dictates the order in which LSPs can be nested. This hierarchy is based on the multiplexing capability of the LSP types. Note that LSPs always start and terminate on similar equipment (e.g., a lambda LSP originates and terminates on a device that sup-ports lambdas). At the top of this hierarchy are nodes that have fiber-switch-capable (FSC) interfaces, followed by nodes that have lambda-switch-capable (LSC) interfaces, followed by nodes that have TDM-capable interfaces, followed by nodes with packet-switch-capable (PSC) interfaces. In a typical configuration (Fig. 3), the core cloud of FSC interfaces/nodes are connected to an outer cloud of LSC interfaces/nodes. These are connected to an outer cloud of TDM-capable nodes, which are finally connected to routers. Dissemination of this information is essential so that the paths within the clouds can be generated automatically with minimal manual configuration.

An LSP (Fig. 3) that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP of type TDM that starts and ends on a TDM interface (i.e., within nodes depicted as a TDM cloud in the picture). This TDM-LSP, in turn, can be nested (together with other TDM-LSPs) into an LSC-LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSC-LSPs) into an LSP that starts and ends on an FSC interface. The LSPs appear as new link types in the IS-IS/ OSPF routing database; the new link types are compatible with the existing flooding methods used for sharing conventional link information. Because of this flooding, each node has an identical link state database containing informa-tion about not just conventional links, but LSPs as well. A node, when performing path computation, is thus able to use not only conventional links, but also LSPs with appropriate constraints (e.g., the order of LSP tunneling has to be main-tained). For more details, the reader is referred to [13]. This allows for hierarchical scaling of the link state database. Once a path is computed, the node uses RSVP/CR-LDP signaling mechanisms to establish label binding along the path. The details of the signaling mechanisms are beyond the scope of this article (see [9]).

LINK BUNDLING

As mentioned above, the link state database consists of all the nodes and links in a network, along with the attributes of each link. In light of issue 3a above, the link state database for an optical network can easily be several orders of magnitude bigger than that for an MPLS network. To address this issue, we aggregate the link attributes of several parallel links of similar characteristics, and assign these aggregated attributes to a single “bundled” link. In so doing, the size of the link state database is reduced by a large factor, leading to vastly improved scaling of the link state protocol. The details of how links are bundled (i.e., how link attributes are aggre-gated) can be found in [14].

By summarizing the attributes of several links into one bundled link, some information is lost; for example, with a bundle of SONET links the switching capability of the link interfaces (OC-12, OC-48, OC-192) are flooded; however, the number of such interfaces and the exact time slots used are not announced. However, the benefit of improved scalability will significantly outweigh the value of the information lost. In addition, while the link state protocol carries a single bundled link, signaling requires that individual component links be identified. LMP [6] offers a means to accomplish this.

UNNUMBERED LINKS

All the links in an MPLS network are typically assigned IP addresses. When a path is computed through the network, the links that constitute the path are identified by their IP addresses; this information is conveyed to the signaling protocol, which then sets up the path. Thus, it would seem that every link must have an IP address. However, issue 3b describes the difficulty of doing this. Unnumbered links are used to resolve this problem; however, if an IP address is not used to identify a link, an alternative must be substituted. What is required is a unique means of identifying links in a network; the task may be broken down into two steps. First, a mechanism is required to uniquely identify each node in the network; then each link emanating from that node is identified. Each node in the network is identified by a unique router ID; what remains is the latter problem of identifying the links emanating from a particular node. A solution to this problem, and the information that needs to be flooded by the routing protocols (OSPF and IS-IS) and that which needs to be communicated by the use of the signaling protocol, are described in [15]. Ultimately, each network node numbers its interfaces locally. The tuple [router ID, link number] serves as the identification for a link. The reduction of management effort in configuring IP addresses, tracking allocated IP addresses, and dealing with the occasional duplicate address allocation is a significant savings, especially in the context of optical networks with their large numbers of links.