idnits 2.17.1 draft-li-mpls-igp-te-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 399 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 221 has weird spacing: '...ain and insur...' -- 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 (February 1999) is 9196 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) == Outdated reference: A later version (-01) exists of draft-ietf-mpls-traffic-eng-00 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-traffic-eng (ref. '1') == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-00 -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2370 (ref. '6') (Obsoleted by RFC 5250) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tony Li 3 INTERNET DRAFT Juniper Networks 4 Expiration Date: August 1999 5 George Swallow 6 Cisco Systems 8 Daniel O. Awduche 9 UUNET 11 February 1999 13 IGP Requirements for Traffic Engineering with MPLS 15 17 Status 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 1.0 Abstract 40 This document describes the functional requirements for an IGP to 41 support Traffic Engineering with MPLS. This document does not specify 42 the protocol changes necessary to realize these requirements. 44 2.0 Introduction 46 A description of the requirements for Traffic Engineering with MPLS 47 can be found in [1]. This document describes the functional 48 requirements to enable a domain's IGP to provide the information 49 necessary to perform important aspects of the traffic engineering 50 function. 52 An important aspect of traffic engineering concerns the procedures 53 and supporting mechanisms employed to compute a path through a 54 domain's network topology. Once a suitable path is computed, a 55 signaling protocol is used to establish a Label Switched Path (LSP) 56 along that path, and traffic that satisfies a given forwarding 57 equivalence relation is sent down the LSP. In general, path 58 computation for an LSP may seek to satisfy a set of requirements 59 associated with the LSP, taking into account a set of constraints 60 imposed by administrative policies and the prevailing state of the 61 network -- which usually relates to topology data and resource 62 availability. Computation of an engineered path that satisfies an 63 arbitrary set of constraints is referred to as "constraint based 64 routing" [1]. Paths computed for an LSP based on constraint based 65 routing can differ from the shortest path that would normally be 66 determined by a domain's IGP. 68 Traffic engineering manipulates the parameters associated with 69 constraint based routing to achieve specific performance objectives, 70 based on a service provider's policies and preferences. 72 Optimal path computation under constraints is computationally 73 expensive. For this reason, online algorithms that are used for this 74 purpose tend to be heuristics that produce reasonable, but suboptimal 75 results in real time. In certain cases, explicit human intervention 76 might be necessary, in the form of engineered paths that are 77 determined off-line and then instantiated through administrative 78 configuration. 80 Because the human component does not scale well with network size and 81 is not predictably responsive, it is beneficial to automate the path 82 computation as much as possible for common cases. In the event that 83 the common cases are not sufficient in the long run to achieve 84 traffic engineering objectives, the requirements stated in this memo 85 are sufficiently flexible so that additional complexity in the path 86 computation can be incorporated in the future. This is possible 87 because all path computation is performed by the originator of the 88 LSP (the head-end). As such, interoperability is constrained to 89 information distribution in the IGP and the basic signaling protocol 90 mechanisms. 92 3.0 Architectural Requirements 94 The architectural requirements consist of two basic components (1) a 95 constraint based routing process that is implemented on those label 96 switching routers that can serve as head-ends for LSPs, and (2) a set 97 of mechanisms for dissemination and maintenance of topology state 98 information. We will focus only on those aspects which are required 99 for interoperable implementations, namely the set of mechanisms used 100 for dissemination of topology state information. Topology state 101 information can be disseminated by extending an IGP so that it 102 conveys additional details concerning the state of the network. 104 Because the IGP is used solely for conveyance of information about 105 the network to the head-end, the attributes of the IGP are somewhat 106 constrained. Computation of alternative paths implies that the 107 head-end knows about alternative links that would not be used by a 108 shortest path computation. This requirement implies that distance 109 vector protocols, which only propagate information about paths that 110 have already been selected, are not appropriate for this application. 112 The other relevant category of IGPs is the class of link state 113 protocols. There are two link state protocols commonly in use: OSPF 114 [3] and IS-IS [4,5]. Link state protocols function by distributing 115 complete topology information about an area to all nodes within the 116 area. In particular, link state protocols are the only known class of 117 protocols that are capable of full topology dissemination. Link 118 state protocols are particularly useful for the traffic engineering 119 application because they can be easily extended to distribute 120 additional information concerning the state of the network. 121 Accordingly, this manuscript describes traffic engineering 122 requirements for link state IGPs only. 124 Because the intent is to add new parameters to the IGP so that the 125 IGP can distribute additional information about the network, the IGP 126 must be extensible. Furthermore, for practical reasons, the 127 extension mechanism must be backward compatible, that is, the 128 existing implementations must continue to function following the 129 changes necessary to support traffic engineering. Specifically, it is 130 desireable that a given IGP domain remain operational when populated 131 with a hybrid of devices, only a subset of which support the traffic 132 engineering extensions. 134 Fortunately, both OSPF and IS-IS satisfy this requirement. OSPF 135 provides an Opaque LSA which can be used to carry arbitrary 136 information [6]. Opaque LSAs are ignored by systems that do not 137 recognize their contents. IS-IS encodes all of the information in 138 its link state packets in tuples described by a type, length and 139 value (TLVs). TLVs that are not recognized by a system are ignored 140 This makes it possible to add information to each protocol in a 141 backward compatible manner. 143 Link state protocols have an inherent shortcoming when used for 144 traffic engineering. Because link state protocols distribute large 145 databases of information and attempt to do so in a timely manner, the 146 size of the database distribution area must necessarily be 147 restricted. The scalability limitations of the flooding algorithms 148 used for link state protocols imply that an upper bound must be 149 imposed on the amount of topology state information that can be 150 distributed for traffic engineering. Additional considerations 151 pertain to the trigger events that cause topology state information 152 to be distributed and the relative frequency of such distributions. 154 Solving the problem of control of topology state information 155 distribution inherent in link state protocols is beyond the scope of 156 this document. However, a solution is required to provide domain-wide 157 traffic engineering in conjunction with a hierarchical IGP. We expect 158 these problems to be addressed in documents that explicitly specify 159 the protocol extensions for each IGP. 161 4.0 Data Distribution Requirements 163 In addition to the requirement for distributing the basic topology of 164 the traffic engineering domain, the IGP is required to transport 165 other information about the network. This section describes the 166 required information. Much of this information provides finer 167 granularity details about the links in the network. 169 To determine if the bandwidth requirements of an LSP will be 170 accommodated on a particular link, it is necessary to know the 171 bandwidth available on that link. Knowledge of bandwidth already 172 consumed on the link is quite useful too. Also, if the domain's 173 administrators impose a constraint on the proportion of a link's 174 bandwidth that can be reserved, pertinent information regarding such 175 reserveable bandwidth must be distributed. 177 Another complication is introduced by the presence of multi-access, 178 full duplex links with non-shared bandwidth. Currently, a common 179 example of such a link is a switched Ethernet. Because each port on 180 the switch has independent bandwidth, the inbound and outbound 181 bandwidth on each interface must be tracked independently. To see 182 the need for this more clearly, suppose that there is a Fast Ethernet 183 (100Mbps) switch with three systems on it, say A, B, and C. Suppose 184 that there is 100Mbps of reserved bandwidth from A to B. Notice that 185 we can now reserve 100Mbps of bandwidth from B to C. 187 However, if we try to reserve any bandwidth from C to B, we find that 188 B's input is already saturated. This is true despite the fact that 189 there is no reserved bandwidth on C's output. This example 190 demonstrates that it is necessary to track and advertise reserved 191 bandwidth on output interfaces, and for some interface types, it is 192 necessary to track and advertise the reserved bandwidth on input 193 interfaces as well. 195 Hybrid links, which are comprised of different components operating 196 at layer 2, are beyond the scope of this document. Such a hybrid link 197 might, for example, be constructed by mixing an Ethernet switch with 198 Ethernet hubs. Two systems that share a common hub only have the 199 common bandwidth of the hub. However, systems that are directly on 200 the switch can have the full-duplex bandwidth of each switch port 201 available. The complexity of modeling such situations is a subject 202 for future research and development. 204 4.1 Specific Data Element Requirements 206 To be used for traffic engineering, an IGP should be able to 207 transport at least the following data elements: 209 4.1.1 Maximum Link Bandwidth 211 The maximum bandwidth available on a link. The amount of bandwidth 212 is normally determined by the type of the physical link, or by 213 traffic shaping parameters on NBMA interfaces. 215 4.1.2 Maximum Reservation Bandwidth 217 The maximum total amount of bandwidth that can be reserved on an 218 interface. Note that this may differ from the maximum bandwidth 219 because administrators may choose to dedicate only part of the link's 220 bandwidth to traffic engineering. Conversely, to exploit statistical 221 multiplexing gain and insure high line utilization, the reservable 222 bandwidth may exceed the actual bandwidth of the link. If the 223 interface is a full-duplex multi-access interface, it is necessary to 224 distribute both the maximum total amount of output bandwidth and the 225 maximum total amount of input bandwidth. 227 4.1.3 Interface IP Address 229 For point-to-point links, a protocol must be able to distribute the 230 IP address of the system at the other end of the link. For multi- 231 access links, a protocol must advertise the IP address of its 232 interface into the multi-access link. These addresses are necessary 233 for Constraint Based Routing to specify the path in the Explicit 234 Route Object that is used by signaling protocols such as RSVP [2]. 236 4.1.4 Resource Class Attribute 238 The resource class attributes for the link. The resource class is 239 used by Constraint Based Routing as a means of determining which 240 links are acceptable for a particular LSP, based on configured 241 administrative policy. 243 4.1.5 Reserved Bandwidth 245 The current amount of reserved bandwidth on the interface. Because 246 traffic engineering supports preemption and multiple levels of 247 priority, remote systems need to know the reserved bandwidth on a 248 per-priority basis. Thus, a protocol must be able to communicate the 249 amount of bandwidth reserved by each priority level. There are eight 250 priority levels. Once again, if the interface is a full-duplex 251 multi-access interface, it is necessary to distribute information on 252 the current amount of reserved bandwidth for both the input and the 253 output sides of the interface. 255 4.2 Comments 257 Note that among these data elements, only the amount of bandwidth 258 currently reserved and the actual bandwidth utilization are expected 259 to be dynamic. All other data elements are not expected to change 260 frequently. Any system generating the dynamic data elements must be 261 careful to limit the frequency with which it distributes these data 262 elements. The exact specification of such rate limiting is beyond 263 the scope of this document. 265 While these data elements are necessary for traffic engineering, the 266 system may also take into account other data elements supported by a 267 protocol or an implementation when performing path computation. 269 5.0 Acknowledgments 271 The authors would like to thank Henk Smit and Der-Hwa Gan for their 272 contributions. Also Curtis Villamizar, Dave Katz, and Joe Malcolm 273 have provided valuable comments. 275 6.0 References 277 [1] "Requirements for Traffic Engineering Over MPLS", D. Awduche, J. 278 Malcolm, J. Agogbua, M. O'Dell, J. McManus, work in progress, draft- 279 ietf-mpls-traffic-eng-00.txt, October 1998. 281 [2] "Extensions to RSVP for LSP Tunnels", D. Awduche, L. Berger, D. 282 Gan, T. Li, G. Swallow, V. Srinivasan, work in progress, draft-ietf- 283 mpls-rsvp-lsp-tunnel-00.txt, November 1998. 285 [3] "OSPF Version 2", J. Moy, RFC 2328, April 1998. 287 [4] "Intermediate System to Intermediate System Intra-Domain Routeing 288 Exchange Protocol for use in Conjunction with the Protocol for 289 Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 290 10589, February 1990. 292 [5] "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 293 R. Callon, RFC 1195, Dec. 1990. 295 [6] "Opaque LSA", R. Coltun, RFC 2370, July 1998. 297 7.0 Authors' Addresses 299 Tony Li 300 Juniper Networks, Inc. 301 385 Ravendale Dr. 302 Mountain View, CA 94043 303 Email: tli@juniper.net 304 Fax: +1 650 526 8001 305 Voice: +1 650 526 8006 307 George Swallow 308 Cisco Systems, Inc. 309 250 Apollo Dr. 310 Chelmsford, MA 01824 311 Email: swallow@cisco.com 312 Voice: +1 978 244 8143 314 Daniel O. Awduche 315 UUNET (MCI Worldcom) 316 3060 Williams Drive 317 Fairfax, VA 22031 318 Email: awduche@uu.net 319 Voice: +1 703 208 5277