Internet Draft MPLS Working Group Suresh Katukam Internet Draft Cisco Systems Expiration Date: January 2001 Handling BLSR with MPLS Traffic Engineering draft-katukam-blsr-te-00.txt 1. 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. 2. Abstract This document outlines procedures needed when applying MPLS TE Control Plane to SONET/SDH Cross-Connects that use BLSR. draft-katukam-blsr-te-00.txt [Page 1] Internet Draft draft-katukam-blsr-te-00.txt July 2000 3. Special consideration for BLSR in SONET/SDH When establishing LSPs over SONET/SDH Cross Connects, BLSR has a special requirement. BLSR standard states that same time slots must be assigned on BLSR links for any given LSP. If a LSP that consists of multiple "contiguous" links of a BLSR, it must have same time slots assigned on all of the BLSR links. If a LSP goes through multiple BLSRs, then this requirement applies to an individual BLSR and not across all BLSRs. For example, say, a STS-3c LSP uses three contiguous links of a BLSR. If time slots 4, 5, 6 are assigned on the first link of BLSR, then same time slots must be assigned on other two links. Inorder to meet this requirement, the source of the circuit need to know currently available channels on all BLSR links. For example, an OC-192 link requires advertising all available (upto 192) channels. This results in a very lengthy advertisement. All nodes need to advertise this LSA whenever a channel is allocated or freed. In order to achieve this effectively in conjunction with the MPLS TE Control plane, the following mechanism should be applied for BLSR. Every node of a BLSR is aware of all links of BLSR and all available channels on those links. With this information, a BLSR node advertises a virtual link to every other node in the ring. This virtual tunnel is like a LSP tunnel (or a logical link from one node to another node ) which has SONET link properties. This link should be considered like any other SONET link. This link consists of two or more physical links that belong to BLSR. When a node advertises such a link, it should compute the Minimum Reservable Bandwidth and Maximum Reservable Bandwidth for that link while considering BLSR requirement and currently available channels on it's physical links. These computed values should be advertised in LSP descriptor as described in [g-mpls-routing]. In any BLSR, there are two paths from a given node to every other node. It is up to the node to determine which path to be used for virtual tunnel. Once it determines a path, it advertises LSP descriptor appropriately for LSP tunnel. In Link Protection sub-TLV, it should be advertised as BLSR protection with BLSR Id. BLSR id should be unique within an OSPF area. Inorder to meet BLSR requirement, path computation algorithm should not consider two or more contiguous BLSR links (physical or LSP tunnels ) of a given BLSR in the shortest path. It can consider multiple BLSR links which are not contiguous for the shortest path computation. draft-katukam-blsr-te-00.txt [Page 2] Internet Draft draft-katukam-blsr-te-00.txt July 2000 4. Example Consider an OC-192 BLSR with 6 nodes A, B, C, D, E, F as shown below: +---+ +---+ | B | ------- | C | +---+ +---+ / \ / \ / \ +---+ +---+ | A | BLSR ID = 1 | D | +---+ +---+ \ / \ / \ / +---+ +---+ | F | ------- | E | +---+ +---+ Node A advertises 5 links corresponding to this BLSR. A has two direct physical links to B and F. Node A creates virtual tunnels to C, D, E and advertises into its area. Node A gives the following view to all other nodes in its area: +---+ +---+ | B | | C | +---+ +---+ / / / /------+ / +------+ +---+ / +---+ | A | --------------------------- | D | +---+ \ +---+ \ +----+ \ \ \ ------+ \ \ +---+ +---+ | F | | E | +---+ +---+ A virtual tunnel from node A to node C can go via B or via F, E, D nodes. It is up to node A to decide which path is better based on its own local criterion such as number of hops, # of available channels etc. It could balance load on these two paths draft-katukam-blsr-te-00.txt [Page 3] Internet Draft draft-katukam-blsr-te-00.txt July 2000 appropriately. For virtual tunnel to C, node A computes min and max reservable bandwidth based on A - B, B - C links OR A - F, F- E, E - D, D - C links. It advertises this information in LSP descriptor. 5. Analysis Current SONET standards define maximum nodes in a BLSR to be 16. Usually, BLSRs are deployed with fewer nodes which is much less than 16. Let us say that there are "N" nodes in a BLSR. If a node advertises virtual tunnels as described above, there can be atmost "N-1" total linksi per node. As per standard OSPF, each node needs to advertise two physical links of BLSR (east side and west side links). Above mechanism adds "N-3" new links to the OSPF topology. It may be possible that a node decides not to advertise a virtual tunnel for many different reasons. For example, say, two nodes of a BLSR have only two links which belong to BLSR. These two nodes do not have any other links that are connected to other nodes. In such a case, there is no need to advertise a virtual tunnel between these two nodes. 6. Security Considerations Security issues are not discussed in this document. 7. Acknowledgements Thanks to Venkataraman Anand, Dave Hillard and Anix Anbiah for insightful discussions and their comments. Special thanks to Yakov Rekhter for all his help while writing the draft. 8. References [g-mpls-routing] 9. Author Information Suresh Katukam Cisco Systems e-mail: skatukam@cisco.com 1450 N. McDowell Blvd, Petaluma, CA 94954-6515 USA draft-katukam-blsr-te-00.txt [Page 4]