idnits 2.17.1 draft-shiomoto-ccamp-multiarea-te-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7983 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'OSPF' on line 319 looks like a reference -- Missing reference section? 'ISIS' on line 322 looks like a reference -- Missing reference section? 'RFC2702' on line 325 looks like a reference -- Missing reference section? 'Wang99' on line 334 looks like a reference -- Missing reference section? 'Xiao00' on line 338 looks like a reference -- Missing reference section? 'ID-Kompella02' on line 341 looks like a reference -- Missing reference section? 'LSP-HIER' on line 344 looks like a reference -- Missing reference section? 'Ramaswami96' on line 347 looks like a reference -- Missing reference section? 'Kar00' on line 351 looks like a reference -- Missing reference section? 'Oki02' on line 356 looks like a reference -- Missing reference section? 'RFC3209' on line 328 looks like a reference -- Missing reference section? 'RFC3212' on line 331 looks like a reference -- Missing reference section? 'GMPLS-ROUT' on line 361 looks like a reference -- Missing reference section? 'GMPLS-OSPF' on line 364 looks like a reference -- Missing reference section? 'TE-OSPF' on line 367 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Kohei Shiomoto (NTT) 3 Internet Draft Eiji Oki (NTT) 4 Expiration Date: December 2002 Masaru Katayama (NTT) 5 Wataru Imajuku (NTT) 6 Naoaki Yamanaka (NTT) 8 June 2002 10 Multi-area multi-layer traffic engineering using 11 hierarchical LSPs in GMPLS networks 12 draft-shiomoto-ccamp-multiarea-te-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This draft proposes a traffic engineering framework for multi-layer path 41 networks using dynamic virtual topology configuration capability of 42 GMPLS protocols. The electrical label switched path is routed over the 43 virtual topology built on a set of optical label switched path in multi- 44 layer path networks. The virtual topology is dynamically altered by 45 setting up or tearing down optical label switched paths. Virtual topol- 46 ogy is configured in response to traffic demand change so that conges- 47 tion of the network is mitigated. Utilization of label switched path is 48 measured at ingress node and disseminated with routing protocol 49 extensions for the individual node to decide whether the virtual topol- 50 ogy should be altered or not without centralized coordination. 52 1. Summary for Sub-IP Area 54 1.1. Summary 56 See the Abstract above. 58 1.2. RELATED DOCUMENTS 60 "Multi-area MPLS traffic engineering," draft-kompella-mpls-multiarea- 61 te-03.txt (work in progress), 5/02. 63 1.3. Where does it fit in the Picture of the Sub-IP Work 65 This work fits the CCAMP box. 67 1.4. Why is it Targeted at this WG 69 This draft is targeted at the CCAMP WG because it addresses the traffic 70 engineering in multi-area multi-layer domain. The topic is in the scope 71 of the work item on how the properties of network resources gathered by 72 the measurement protocol can be distributed in existing routing proto- 73 cols, such as OSPF and IS-IS. 75 1.5. Justification of Work 77 The WG should consider this document as it addresses a new traffic engi- 78 neering framework using dynamic virtual topology configuration mechanism 79 in multi-layer path network, which is enabled by GMPLS protocols. 81 2. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC-2119. 87 3. Introduction 89 GMPLS provides a protocol framework for multi-layer path network con- 90 trol. Label switched paths (LSPs) in fiber-, lambda-, SDH/SONET-, and 91 IP-layers can be set up by using GMPLS signaling and routing protocols. 92 The lower-layer LSP provides a (virtual) topology for the upper-layer 93 LSP routing in multi-layer path network. In particular non-packet capa- 94 ble LSP (fiber, lambda, SDH/SONET), which has a fixed capacity, con- 95 structs a "hard" virtual topology for packet capable LSP routing. The 96 virtual topology can be quickly re-configured using GMPLS routing and 97 signaling protocols to set up the lower-layer LSPs. 99 Promising application of GMPLS-based multi-layer path network control 100 includes traffic engineering. A new traffic engineering framework can 101 be constructed in multi-layer path networks. This draft proposes a 102 traffic engineering method based on the quick virtual topology configu- 103 ration. The rest of the draft is organized as follows. Firstly we 104 briefly review the current traffic engineering methods for fixed network 105 topology. Secondly we show the concept of the proposed traffic engi- 106 neering method based on the quick virtual topology configuration. 107 Multi-area network whose backbone area is optical-layer network and 108 other areas are electrical IP-layer networks is used for network model. 109 Thirdly we provide protocol extensions for the proposed method. 111 4. Current traffic engineering in MPLS 113 Conventional routing protocol computes the path which minimizes its cost 114 using the shortest path algorithm [OSPF,ISIS]. Packets are forwarded 115 along with the shortest path even if the intermediate links do not have 116 sufficient bandwidth, which result in congestion. To overcome the con- 117 gestion cased by IGP's shortest path routing, MPLS-based traffic engi- 118 neering has been extensively studied recently [RFC2702]. Explicit route 119 for LSP can be used so as to avoid congestion in MPLS framework. Con- 120 straint-based shortest path first (CSPF) algorithm selects the path with 121 minimum cost assuming that links which do not have sufficient bandwidth 122 are excluded from the network topology. If the requested bandwidth for 123 the LSP is given, the CSPF algorithm calculates the path which satisfies 124 the requested bandwidth. The path for the LSP is specified at the 125 source node and the LSP is set up along with the path [RFC3209, 126 RFC3212]. 128 LSP which requests a specified bandwidth is served in first-come-first- 129 served basis. As the number of such LSPs increases, the network uti- 130 lization might not get optimized: some links might be congested while 131 others not. Explicit route for existing LSPs need to be re-optimized 132 for better network utilization. Several network optimization methods 133 have been developed. In [Wang99], given the traffic demand matrix whose 134 (i,j) element corresponds to the traffic demand from the node i to j, 135 linear and integer programming formulations are used to minimize the 136 utilization of the most congested link. In [Xiao00], LSP is arbitrarily 137 routed at first to obtain the traffic demand matrix and a simple CSPF 138 algorithm is applied to find the route of the LSP in descending order of 139 its traffic demand volume. 141 Those traffic engineering methods are developed under the assumption 142 that the underlying network topology is fixed. The network utilization 143 is, however, limited under the fixed underlying network topology. This 144 draft proposes a traffic engineering method using the dynamic reconfigu- 145 ration of virtual topology in multi-layer path network. In particular 146 we address the method for two-layer network in which the lower-layer is 147 photonic network and the upper-layer is IP packet network. 149 5. Dynamic reconfiguration of virtual topology in Photonic IP multi- 150 layer network 152 5.1. Network model 154 Multi-area network whose backbone area is optical-layer network and 155 other areas are electrical IP-layer networks is used for network model 156 [ID-Kompella02]. Photonic layer provides a virtual topology for IP 157 layer in Photonic IP multi-layer network. Optical LSP, which is set up 158 to connect two electrical LSRs, is advertised as FA-LSP [LSP-HIER]. A 159 set of those FA-LSPs forms the virtual network topology for electrical 160 LSP routing. Electrical LSP is routed over the virtual network topol- 161 ogy. 163 Figure 1 shows the multi-area network with photonic core backbone area. 164 Electrical areas (areas 1, 2, and 3) consist of LSRs while the photonic 165 backbone-area consists of PXCs. The electrical areas are connected with 166 the photonic backbone area (area 0) at the ABRs 1, 2, and 3, respec- 167 tively. 169 -------------+ +-----------------+ +---------- 170 area1 | | area 0 | | area2 171 (Ingress) | | (Photonic core | | (Egress) 172 | | backbone area) | | 173 +-----+ +-----+ +-----+ +-----+ +-----+ 174 | | | | | | | | | | 175 --| LSR1+--+ ABR1+---+ PXC1+---+ ABR2+--+ LSR2+-- 176 | | | | | | | | | | 177 +-----+ +-----+ +--|--+ +-----+ +-----+ 178 | | | | | 179 | | +-----+ | | 180 ------------+ | | | | +----------- 181 | | PXC2| | +---------- 182 | | | | | area3 183 | +-----+ | | (Egress) 184 | | | | 185 | +-----+ +-----+ +-----+ 186 | | | | | | | 187 | | PXC3|---| ABR3+--| LSR3|- 188 | | | | | | | 189 | +-----+ +-----+ +-----+ 190 | | | 191 | | | 192 +-----------------+ +---------- 194 Figure 1: Multi-area network with photonic backbone. 196 E-LSPs are set up between ABRs in distant area so that all areas are 197 mutually interconnected in a full-mesh manner. Those E-LSPs are used to 198 carry packets over the photonic backbone area. The photonic backbone 199 area provides a virtual topology for E-LSP routing. The O-LSP is set up 200 over the photonic backbone area to connect ABRs in distant electrical 201 areas. The O-LSPs need to be set up so that all areas are mutually 202 interconnected via E-LSPs in a full-mesh manner. We should note that 203 not all ABRs are directly connected each other via an O-LSP. E-LSP uses 204 single-hop or multi-hop O-LSPs from ingress to egress areas. In some 205 cases an E-LSP may be routed over a single-hop O-LSP, which directly 206 connects the ingress and egress areas. In other cases an E-LSP may be 207 routed over multi-hop O-LSPs, by which the ingress area is electrically 208 reachable to the egress area. 210 Two virtual optical backbone area topologies are explained using the 211 sample network in Figure 1. Suppose that the O-LSP is already set up 212 between ABR 2 and ABR 3. In this situation if the traffic demand 213 between area 1 and area 2 is higher than that between area 1 and area 3, 214 the O-LSP should be set up between ABR 1 and ABR 2. In this case the 215 virtual optical backbone area topology is shown in Figure 2 (a). The E- 216 LSPs are routed over the virtual optical backbone area topology. The E- 217 LSP from area 1 to area 3 is routed over a two-hop path passing through 218 area 1, 2, and 3 while the E-LSP from area 1 to area 2 is routed over a 219 single-hop path passing through area 1 and 2. On the other hand, if the 220 traffic demand between area 1 and area 3 is higher than that between 221 area 1 and area 2, the O-LSP should be set up between ABR 1 and ABR 3. 222 In this case the virtual optical backbone area topology is shown in Fig- 223 ure 2 (b). 225 +-------+ +-------+ +-------+ +-------+ 226 | | | | | | | | 227 | Area1 +-----+ Area2 | | Area1 | | Area2 | 228 | | | | | | | | 229 +-------+ +---+---+ +---+---+ +---+---+ 230 | | | 231 | | | 232 +---+---+ | +---+---+ 233 | | | | | 234 | Area3 | +---------+ Area3 | 235 | | | | 236 +-------+ +-------+ 238 (a) (b) 240 Figure 2: Virtual topology of backbone area. 242 5.2. Dynamic reconfiguration of virtual topology 244 The virtual backbone area topology should adjust to traffic demand 245 change [Ramaswami96, Kar00, Oki02]. If traffic demand for E-LSPs are 246 given, appropriate virtual optical backbone area topology could be 247 determined. In determining the virtual topology we use a heuristic 248 method in which O-LSP is set up between node pair in the descending 249 order of traffic demand between them. The idea behind the method is 250 that sending most of traffic in a single-hop may reduce congestion. We 251 need to determine the virtual topology such that we make the best use of 252 the O-LSP bandwidth because the O-LSP occupies the fixed bandwidth once 253 it is established. When the O-LSP gets underutilized, it should be 254 released for future demand of another O-LSP. 256 The dynamic reconfiguration of the virtual topology can be implemented 257 with either centralized or distributed approach. In centralized 258 approach, a central network management system collects traffic demand 259 over the E-LSP measured by all nodes in the network, calculates a new 260 virtual topology, and dictates appropriate nodes to initiate O-LSP setup 261 procedure. In distributed approach, each node decides whether it should 262 initiate O-LSP setup procedure or not. In this draft we take the dis- 263 tributed approach because the centralized one suffers from reliability 264 problem due to single point of failure. 266 The distributed approach requires a mechanism for coordination between 267 nodes. Unless coordination mechanism is properly implemented, a new 268 virtual topology might be formed inconsistently. To overcome this prob- 269 lem, LSP bandwidth utilization is measured at ingress node and it is 270 disseminated to all nodes in the domain. Each node calculates the next 271 virtual topology to mitigate the congestion using bandwidth utilization 272 for E-LSP and O-LSP disseminated by its ingress node. Each node decides 273 whether it should initiate O-LSP setup procedure or not by comparing the 274 current virtual topology and the next one. 276 6. Protocol extensions 278 6.1. Routing protocol extensions for LSP utilization dissemination 280 O-LSP utilization is measured at ingress LSR. Measured O-LSP utiliza- 281 tion is disseminated by routing protocol. Area local Opaque LSA (type 282 10) is used to carry the measured OLSP utilization [GMPLS-ROUT, GMPLS- 283 OSPF, TE-OSPF]. Format of sub-TLV for the measured O-LSP utilization is 284 shown in Figure 3. The measured O-LSP utilization is disseminated to 285 notify individual nodes of that congestion occurs in the network. 287 E-LSP utilization is measured at ingress LSR. Measured E-LSP utiliza- 288 tion is disseminated by routing protocol. Area local Opaque LSA (type 289 10) is used to carry the measured E-LSP utilization. Format of sub-TLV 290 for the measured E-LSP utilization is shown in Figure 3. The measured 291 E-LSP utilization is used for individual node to calculate the next vir- 292 tual topology to mitigate congestion. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Measured LSP utilization (MBytes/s) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 3: Traffic demand sub-TLV for OSPF extensions. 304 7. Conclusions 306 GMPLS protocols open a new vista for multi-layer path network control. 307 The traffic engineering method using dynamic reconfiguration of virtual 308 topology is a promising application of GMPLS protocols in multi-layer 309 path networks. Detailed protocol mechanisms for interwork between lay- 310 ers in multi-path network need further study and will be developed in 311 the future version of this draft. 313 8. Security considerations 315 Security issues are not discussed in this draft. 317 9. Reference 319 [OSPF] J. T. Moy, "OSPF: anatomy of an Internet routing protocol," Addi- 320 son-Wesley, 98. 322 [ISIS] R. Callon, "Use of OSI IS-IS for routing in TCP/IP and dual envi- 323 ronments," RFC1195, 12/90. 325 [RFC2702] D. O. Auduche, et al. , "Requirements for traffic engineering 326 over MPLS," RFC 2702, 9/99. 328 [RFC3209] D. O. Auduche, et al. , "RSVP-TE: Extensions to RSVP for LSP 329 tunnels," RFC 3209, 12/01. 331 [RFC3212] B. Jamoussi, et al. "Constraint-based LSP setup using LDP," 332 RFC 3212, 1/02. 334 [Wang99] Y. Wang and Z. Wang, "Explicit routing algorithms for Internet 335 traffic engineering," In Proc. of IEEE IC3N, pp. 582-588, Boston, MA, 336 10/99. 338 [Xiao00] X. Xiao, A. Hannan, B. Bailey, and L. M. Ni, "Traffic engineer- 339 ing with MPLS in the Internet," IEEE Network Magazine, pp.28-33, 3-4/00. 341 [ID-Kompella02] "Multi-area MPLS traffic engineering," draft-kompella- 342 mpls-multiarea-te-03.txt (work in progress), 5/02. 344 [LSP-HIER] "LSP hierarchy with MPLS TE," draft-ietf-mpls-lsp-hierar- 345 chy-06.txt (work in progress), 5/02. 347 [Ramaswami96] R. Ramaswami and K. N. Sivarajan, "Design of logical 348 topologies for wavelength-routed optical networks," IEEE J. Select. 349 Areas in Commun., pp. 840-851, Vol. 14, No. 5, 6/96. 351 [Kar00] K. Kar, M. Kodialam, and T. V. Lakshman, "Minimum interference 352 routing of bandwidth guaranteed tunnels with MPLS traffic engineering 353 applications," IEEE J. Select. Areas in Commun., pp. 2566-2579, Vol. 18, 354 No. 12, 12/00. 356 [Oki02] E. Oki, K. Shiomoto, S. Okamoto, W. Imajuku, and N. Yamanaka, A 357 heuristic-based multi-layer optimum topology design scheme based on 358 traffic measurement for IP+Photonic networks," In Proc. of OFC 2002, 359 3/2002. 361 [GMPLS-ROUT] "Routing extensions in support of generalized MPLS," draft- 362 many-ccamp-gmpls-routing-04.txt (work in progress), 4/02. 364 [GMPLS-OSPF] "OSPF extensions in support of generalized MPLS," draft- 365 ietf-ccamp-ospf-gmpls-extensions-07.txt (work in progress), 5/02. 367 [TE-OSPF] "Traffic engineering extensions to OSPF," draft-katz-yeung- 368 ospf-traffic-06.txt, 10/01. 370 10. Author information 372 Kohei Shiomoto 373 NTT Network Innovation Laboratories 374 Midori 3-9-11 375 Musashino, Tokyo 180-8585, Japan 376 Email: shiomoto.kohei@lab.ntt.co.jp 378 Eiji Oki 379 NTT Network Innovation Laboratories 380 Midori 3-9-11 381 Musashino, Tokyo 180-8585, Japan 382 Email: oki.eiji@lab.ntt.co.jp 384 Masaru Katayama 385 NTT Network Innovation Laboratories 386 Midori 3-9-11 387 Musashino, Tokyo 180-8585, Japan 388 Email: katy@exa.onlab.ntt.co.jp 390 Wataru Imajuku 391 NTT Network Innovation Laboratories 392 Hikari-no-oka 1-1 393 Yokosuka, Kanagawa 239-0847, Japan 394 Email: Imajuku@exa.onlab.ntt.co.jp 396 Naoaki Yamanaka 397 NTT Network Innovation Laboratories 398 Midori 3-9-11 399 Musashino, Tokyo 180-8585, Japan 400 Email: yamanaka.naoaki@lab.ntt.co.jp