CCAMP Working Group Kohei Shiomoto (NTT) Internet Draft Eiji Oki (NTT) Expiration Date: August 2002 Masaru Katayama (NTT) Wataru Imajuku (NTT) Naoaki Yamanaka (NTT) February 2002 Multi-area multi-layer traffic engineering using hierarchical LSPs in GMPLS networks draft-shiomoto-ccamp-multiarea-te-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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft proposes a multi-area multi-layer traffic engineering method using hierarchical LSPs in GMPLS networks. Lower-layer LSPs are set up between ABRs over the backbone area and higher-layer LSPs are set up between LSRs over the lower-layer LSPs. The proposed method is applied to optical backbone area. OSPF and BGP-4 are extended to carry traffic demand from ingress area to egress area so that each border node can compile the traffic demand matrix whose (i,j)-element corresponds to the traffic demand from area-i to area- j. Appropriate light path topology can be calculated using the traffic demand matrix. Kohei Shiomoto [Page 1] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 1. Multi-area traffic engineering using hierarchical LSPs OSPF/ISIS is used to create the routing table. To scale the OSPF/ISIS multi-area concept was introduced. Areas are interconnected via the special area called backbone area (area 0) in a hub-and-spoke manner. Area border router (ABR) is located at the border between the backbone area and surrounding areas. In this draft we propose traffic engineering using hierarchical LSPs in multi-area network. Figure 1 shows the multi-area network with hierarchical LSPs. We assume that there is one ABR per each surrounding area in this draft. But there is no limitation on the number of ABRs per each surrounding area. LSPs are set up between ABRs in distant area so that all areas are mutually interconnected in full-mesh manner. Those LSPs are used to carry packets over backbone area. Those LSPs are referred to as lower-layer LSP. LSPs are set up between LSRs in ingress and egress areas. Those LSPs are referred to as higher-layer LSP. The higher-layer LSP is routed over the tunnel of lower-layer LSP (See Figure 1). ------------+ +-----------------+ +----------- Area1 | | Area 0 | | Area 2 (Ingress) | | (Backbone area) | | (Egress) | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | ---+ LSR +--+ ABR +---+ LSR +---+ ABR +--+ LSR +-- | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | Higher-layer LSP ------------------------------> Lower-layer LSP ------------> | | | | | | ------------+ +-----------------+ +----------- Figure 1: Multi-area network with hierarchical LSPs. The higher-layer LSP routing is done as follows. The ingress LSR in the ingress area finds the route to the ingress ABR in the ingress area as a result of constraint-based shortest path first (CSPF) algorithm. The ingress ABR in the ingress area checks whether there is sufficient bandwidth along with the lower-layer LSP to the egress area. If there is sufficient bandwidth along with the lower-layer LSP to the egress area, the egress ABR in the egress area finds the route to the egress LSR in the egress area. In summary the ingress LSR takes care of the residual bandwidth in the ingress area, the ingress ABR takes care of the residual bandwidth in the backbone area, and the egress ABR takes care of the residual bandwidth in the egress Kohei Shiomoto [Page 2] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 area. 2. Multi-area multi-layer network with optical backbone area The backbone area could be constructed as an optical network. In what follows we assume that the network consists of optical backbone-area (area 0) and electrical areas. Figure 2 shows the multi-area network with optical core backbone area. Electrical areas (areas 1, 2, and 3) consist of LSRs while the optical backbone-area consists of PXCs. The electrical areas are connected with the optical backbone area (area 0) at the ABRs 1, 2, and 3, respectively. -------------+ +-----------------+ +---------- area1 | | area 0 | | area2 (Ingress) | | (Optical core | | (Egress) | | backbone area) | | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | --| LSR1+--+ ABR1+---+ PXC1+---+ ABR2+--+ LSR2+-- | | | | | | | | | | +-----+ +-----+ +--|--+ +-----+ +-----+ | | | | | | | +-----+ | | ------------+ | | | | +----------- | | PXC2| | +---------- | | | | | area3 | +-----+ | | (Egress) | | | | | +-----+ +-----+ +-----+ | | | | | | | | | PXC3|---| ABR3+--| LSR3|- | | | | | | | | +-----+ +-----+ +-----+ | | | | | | +-----------------+ +---------- Figure 2: Multi-area network with optical backbone. Hierarchical routing is done in this network. The lower-layer electrical LSP (E-LSP) is routed over the light path topology constructed over the optical backbone area. The light path is established to connect ABRs in distant areas. The light path is referred to as O-LSP in this draft. O-LSP is set up over the optical backbone area to connect ABRs in distant electrical areas. The O-LSP is treated as single physical link connecting the adjacent ABRs. Once the O-LSP is set up to connect the distant electrical areas, it Kohei Shiomoto [Page 3] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 can be used to route the (lower-layer) E-LSP between ABRs in ingress and egress areas. An O-LSP or concatenated O-LSPs need to be established between the two ABRs so that the E-LSP can be routed from the source electrical area to the destination electric area over the optical backbone area. In GMPLS networks each link has switching capabilities at both ends [LSP-HIER]. Routing of E-LSP and O-LSP is done by calculating the appropriate path over the link state database. Link-state database is filtered according to the switching capability in calculating the E- LSP path and O-LSP path. In calculating the path for O-LSP, link- state database is filtered to exclude the link, neither end of which includes LSC. On the other hand, in calculating the path for E-LSP, link-state database is filtered to include the link, both ends of which include only PSC. In this way hierarchical topology view is used to route O-LSP and E-LSP in GMPLS networks. Once the O-LSP is set up, it is advertised as TE-link, both ends of which are PSC. The O-LSP is advertised as TE-link. In other words O- LSP is treated in the same way as physical link connecting adjacent LSRs. E-LSP is routed over logical topology consisted of TE-links, both ends of which are PSC. The O-LSP topology provides virtual topology view of the backbone area from the electrical perspective. It is referred to as the virtual backbone area topology hereafter. In this way O-LSP topology in the optical backbone area influences the (lower-layer) E-LSP routing in the backbone area. 3. Traffic engineering in the optical backbone area By using GMPLS signaling and routing the virtual optical backbone area topology can be altered. The virtual backbone area topology should adjust to traffic demand change [RFC2702, Wang99, Kar00, Oki02]. If traffic demand matrix between all surrounding areas is given, appropriate virtual optical backbone area topology could be determined. Two virtual optical backbone area topologies are explained using the sample network in Figure 2. Suppose that the O- LSP is already set up between ABR 2 and ABR 3. In this situation if the traffic demand between area 1 and area 2 is higher than that between area 1 and area 3, the O-LSP should be set up between ABR 1 and ABR 2. The virtual optical backbone area topology looks like Figure 3 (a). The lower-layer E-LSPs are routed over the virtual optical backbone area topology. The E-LSP from area 1 to area 3 is routed over a two-hop path passing through area 1, 2, and 3 while the E-LSP from area 1 to area 2 is routed over a single-hop path passing through area 1 and 2. On the other hand, if the traffic demand between area 1 and area 3 is higher than that between area 1 and area 2, the O-LSP should be set up between ABR 1 and ABR 3. The virtual optical backbone area topology looks like Figure 3 (b). Kohei Shiomoto [Page 4] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 +-------+ +-------+ +-------+ +-------+ | | | | | | | | | Area1 +-----+ Area2 | | Area1 | | Area2 | | | | | | | | | +-------+ +---+---+ +---+---+ +---+---+ | | | | | | +---+---+ | +---+---+ | | | | | | Area3 | +---------+ Area3 | | | | | +-------+ +-------+ (a) (b) Figure 3: Virtual topology of backbone area. For the purpose of traffic engineering of the virtual optical backbone area topology, traffic demand information between areas is needed. Using traffic demand information between areas, O-LSPs are set up directly between appropriate areas. Traffic demand matrix is defined in this draft. Traffic demand matrix is a matrix whose (i,j)-element corresponds to traffic demand from area-i to area-j. Traffic demand from area-i to area-j could be obtained at the ingress area (area-i) from various sources: traffic measurement, guaranteed bandwidth to clients, or forecast in provisioning procedure. By exchanging the traffic demand information among ABRs, traffic demand matrix is compiled by each ABR. Once the traffic demand matrix is compiled, appropriate O-LSP topology could be determined. Each ABR could decide ABRs to which it should set up the direct O-LSP from the appropriate O-LSP topology. 4. Dissemination of traffic demand matrix Traffic demand matrix can be disseminated to all border routers by extending existing routing protocols [OSPF]. OSPF with traffic extensions was proposed [GMPLS-OSPF,TE-OSPF]. Opaque LSA is used to advertise traffic extensions. Type 10 LSA, which has area flooding scope, is used. By adding new sub-TLV called traffic demand (TD) sub- TLV, traffic demand obtained at the ABR is disseminated to all nodes in the backbone area (See Figure 4). Traffic demand matrix is complied at border nodes although TD sub-TLV is disseminated to all nodes (border and core) in the backbone area. IBGP-like mechanism could be used to exchange traffic demand matrix between border nodes. The detail of the extensions of OSPF and BGP-4 will be developed in the future version of this draft. Kohei Shiomoto [Page 5] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress ABR Route ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress ABR Route ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic demand [Mbytes/sec] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress ABR Route ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic demand [Mbytes/sec] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress ABR Route ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic demand [Mbytes/sec] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Traffic demand sub-TLV for OSPF extensions. 5. Security considerations Security issues are not discussed in this draft. 6. Reference [RFC2702] D. O. Auduche, et al. , "Requirements for traffic engineering over MPLS," RFC 2702, 9/99. [Wang99] Y. Wang and Z. Wang, "Explicit routing algorithms for Internet traffic engineering," In Proc. of IEEE IC3N, pp. 582-588, Boston, MA, 10/99. [Kar00] K. Kar, M. Kodialam, and T. V. Lakshman, "Minimum interference routing of bandwidth guaranteed tunnels with MPLS traffic engineering applications," IEEE J. Select. Areas in Commun., pp. 2566-2579, Vol. 18, No. 12, 12/00. [Oki02] E. Oki, K. Shiomoto, S. Okamoto, W. Imajuku, and N. Yamanaka, A heuristic-based multi-layer optimum topology design scheme based on traffic measurement for IP+Photonic networks," In Proc. of OFC 2002, 3/2002. [OSPF] J. T. Moy, "OSPF: anatomy of an Internet routing protocol," Kohei Shiomoto [Page 6] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 Addison-Wesley, 98. [GMPLS-ROUT] "Routing extensions in support of generalized MPLS," draft-many-ccamp-gmpls-routing-01.txt (work in progress), 11/01. [GMPLS-OSPF] "OSPF extensions in support of generalized MPLS," draft- ietf-ccamp-ospf-gmpls-extensions-04.txt (work in progress), 02/02. [TE-OSPF] "Traffic engineering extensions to OSPF," draft-katz-yeung- ospf-traffic-06.txt, 10/01. [LSP-HIER] "LSP hierarchy with MPLS TE," draft-ietf-mpls-lsp- hierarchy-04.txt (work in progress), 02/02. [ID-ASH01] "Requirements for multi-area TE," draft-ash-multi-area-te- reqmts-01.txt (work in progress), 11/01. [ID-Kompella01] "Multi-area MPLS traffic engineering," draft- kompella-mpls-multiarea-te-02.txt (work in progress), 11/01. [ID-Venkatachalam01] " A framework for the LSP setup across IGP areas for MPLS traffic engineering," draft-venkatachalam-interarea-mpls- te-02.txt (work in progress). 7. Author information Kohei Shiomoto NTT Network Innovation Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Eiji Oki NTT Network Innovation Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: oki.eiji@lab.ntt.co.jp Masaru Katayama NTT Network Innovation Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: katy@exa.onlab.ntt.co.jp Wataru Imajuku NTT Network Innovation Laboratories Hikari-no-oka 1-1 Yokosuka, Kanagawa 239-0847, Japan Kohei Shiomoto [Page 7] Kohei Shiomoto draft-shiomoto-multiarea-te-00.txt 22 February 2002 Email: Imajuku@exa.onlab.ntt.co.jp Naoaki Yamanaka NTT Network Innovation Laboratories Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Email: yamanaka.naoaki@lab.ntt.co.jp Kohei Shiomoto [Page 8]