idnits 2.17.1 draft-jamoussi-mpls-sin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 13) being 60 lines == It seems as if not all pages are separated by form feeds - found 13 form feeds but 15 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 39: '... MPLS MUST allow 'ships in the night...' RFC 2119 keyword, line 155: '... "MPLS MUST allow "ships in the ni...' RFC 2119 keyword, line 461: '... the behavior MUST be configurable. ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 217 has weird spacing: '...account the n...' == Line 225 has weird spacing: '...on, and bandw...' == Line 279 has weird spacing: '...work to ensur...' == Line 317 has weird spacing: '... aspect of SI...' == Line 390 has weird spacing: '...irement can b...' == (7 more instances...) -- 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 (August 1998) is 9384 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 (-05) exists of draft-ietf-mpls-framework-02 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- No information found for draft-mpls-ldp - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group B. Jamoussi 3 Internet Draft Nortel Ltd 4 Expiration Date: February 1999 5 N. Feldman 6 IBM Corp 8 L. Andersson 9 Bay Networks Inc 11 August 1998 13 MPLS Ships in the Night Operation with ATM 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 Multi-Protocol Label Switching (MPLS) can have several modes of 38 operation over ATM. The MPLS Framework document [1] indicates that 39 MPLS MUST allow 'ships in the night' (SIN) operation with existing L2 40 switching protocols (e.g., ATM Forum Signaling). 42 This document identifies the technical requirements that have to be 43 resolved in order to allow for a successful SIN operation between 44 MPLS and ATM Forum protocol stack. Solutions to the various 45 challenges are proposed. 47 Table of Contents 49 1 Introduction ......................................... 2 50 1.1 Modes of Operation of MPLS over ATM .................. 2 51 1.2 Benefits of Operating MPLS over ATM .................. 3 52 1.3 Ships in the Night Mode of Operation ................. 4 53 2 VPI.VCI Space Partitioning ......................... 4 54 3 Traffic management ................................... 5 55 3.1 Bandwidth Management ................................. 7 56 3.2 Bandwidth Reservation ................................ 8 57 3.3 Queuing & Scheduling ................................. 9 58 3.4 Alignment with DS-Byte ............................... 10 59 4 Processing Capacity .................................. 11 60 5 Summary .............................................. 11 61 6 Security Considerations .............................. 11 62 7 Acknowledgment ....................................... 11 63 8 References ........................................... 11 64 9 Author's Address ..................................... 12 65 Appendix A Example of Equivalent Rate Computation ............... 13 66 Appendix B Example of ATM and MPLS COS mappings ................. 14 68 1. Introduction 70 In Section 1.1 we summarize the current models of using MPLS over 71 ATM. Section 1.2 highlights the benefits of running MPLS on ATM. In 72 Section 1.3, the requirements for running in Ships in the night (or 73 hybrid) mode are outlined. 75 1.1 Modes of Operation of MPLS over ATM 77 MPLS can have several modes of operation over ATM. This section 78 outlines the various operation modes that have been described so far 79 in various MPLS Internet Drafts. We classify MPLS over ATM modes of 80 operation as follows: 82 1. Use of ATM hardware as a Label-Controlled Interface: 84 a. MPLS-Only: 86 This mode has been described the most in the current MPLS 87 documentation. A label switching control component is 88 developed to control the ATM switching hardware as 89 described in [2]. 91 b. Ships in the night: 93 This mode of operation has not been described in any level of 94 detail in any of the current MPLS drafts. The only mention 95 was to divide the VPI.VCI space between the ATM control plane 96 and the MPLS control plane [1, 2]. Other SIN operation 97 considerations were out of scope in [2]. 99 2. Use of ATM as a bearer service (B-ISDN): 101 a. Use of a VP: 103 A VP is established between two LSRs going across an ATM 104 network. The VCI is used as label within the VP [2, 3]. 106 b. Use of a PVC or SVC and the VCID: 108 A PVC or an SVC is established across an ATM network. 109 The VCID is used to identify the two ends of the LSP [3, 4]. 111 The choice of the model of deployment of MPLS on ATM depends on 112 various factors such as the pre-existence of an ATM network. 114 In the remainder of this document we focus on the ships in the night 115 mode of operation. 117 1.2 Benefits of Operating MPLS over ATM 119 Operating MPLS over an ATM network has many benefits described in 120 this section. Many of the ATM hardware features are readily available 121 to MPLS implementations. 123 - MPLS inherits the ATM hardware label (VPI/VCI) switching. This 124 allows an ATM-LSR to forward packets at very high rates. 126 - ATM's powerful traffic management features that are already 127 embedded in ATM hardware are available for use by MPLS with the 128 proper hooks in the MPLS control software (e.g., LDP). For example, 129 the queuing and scheduling techniques embedded in ATM hardware allow 130 it to provide many classes of service. This maps nicely to the COS 131 field in the LDP protocol. In addition, to queuing and scheduling, 132 you can also make use of traffic shaping and traffic policing at the 133 boundaries between MPLS domains. 135 - The use of ATM-LSRs allows for multiple services (voice, video, and 136 data) to be offered on a single platform. Operating MPLS over ATM 137 reduces the number of infrastructures required to provide multiple 138 services. It is hence possible to offer native ATM, a mixture of 139 Frame and ATM services, as well as MPLS using the same 140 infrastructure. 142 - Protect the capital investment in ATM infrastructure by increasing 143 the utilization of existing ATM network. Allow for an easy migration 144 from IP over ATM to IP over MPLS over ATM. Protect the network 145 management and operational knowledge. 147 - While the MPLS architectures evolves, ATM offers traffic- 148 engineering solutions to solve today's bandwidth constraints. 150 1.3 Ships in the Night Mode 152 Ships in the night (SIN) operation is described in [1]. Section 1.2 153 of [1] includes the following requirement: 155 "MPLS MUST allow "ships in the night" operation with existing layer 156 2 switching protocols (e.g., ATM Forum Signaling) (i.e., MPLS must 157 be capable of being used in the same network which is also 158 simultaneously operating standard layer 2 protocols)." 160 SIN operation means that both MPLS and ATM control and routing 161 software are running on the same network. In addition, both MPLS and 162 ATM traffic share the same network infrastructure. However, both 163 protocols are oblivious to each other. 165 As the deployment of ATM networks continues to grow, it becomes 166 necessary for the successful deployment of MPLS to address the 167 question of how MPLS and ATM would co-exist. 169 The key advantage of running in SIN mode is that an existing Multi- 170 Service ATM network (running the ATM Forum software stack) can be 171 easily shared with MPLS (running IP routing and LDP). However, the 172 successful integration of MPLS and ATM on the same network requires 173 the following issues to be resolved: 175 1. VPI.VCI space partitioning 176 2. Traffic Management 177 3. Processing Capacity (Memory and CPU) 179 2. VPI.VCI Space Partitioning 181 In a label-controlled ATM (LC-ATM) interface, labels are the VPI.VCI 182 fields of the ATM cell. The entire 28-bit VPI.VCI field can be used 183 as a label in a flat hierarchy environment. However, a two level 184 hierarchy can also be achieved by using the VPI and the VCI fields 185 independently; each representing a level of the hierarchy. 187 ATM Forum stack makes use of the same VPI.VCI field to switch ATM 188 cells within a VP or a VC. Therefore, partitioning of the VPI/VCI 189 space (label space) between ATM and MPLS is necessary. 191 This issue is easily resolved through configuration. Two VPI.VCI 192 pools (Label-pool) are configured at start-up time. A Label-pool (a 193 sub-set of the VPI.VCI space) is allocated to ATM and another Label- 194 pool to MPLS. Each system only allocates VPI.VCI resources from its 195 own Label-pool. 197 In keeping with the idea that both ATM and MPLS control planes are 198 oblivious to each other, it's necessary to avoid having one control 199 plane infer parameters based on the configuration of the other 200 control plane. Therefore, the division of label space between ATM and 201 MPLS needs to be pre-configured per interface. The exchange of the 202 valid VPI.VCI range between two adjacent LSRs/ATM switches is done as 203 follows: 205 - MPLS uses the LDP to negotiate the range of 206 valid VPI.VCI labels. This information is exchanged during the 207 initialization phase of the LDP session between two peer LSRs as 208 specified in LDP [5]. 210 - ATM uses the ILMI channel to negotiate the valid VPI.VCI range as 211 specified in [6]. 213 Both LDP and ILMI are currently defined to take the intersection of 214 the VPI.VCI range of two adjacent LSRs and ATM switches respectively. 216 The choice of the boundary between ATM and MPLS is a Network 217 Engineering exercise that takes into account the number of ATM VCs 218 that are expected, whether VC-merge is supported on the interface, 219 the level of stream granularity, among possibly other parameters. 221 3. Traffic Management 223 Traffic Management (TM) is one of the key components of MPLS. 224 Currently, TM is proposed to rely on explicit routing (ER), Class of 225 Service (COS) differentiation, and bandwidth reservation. [7] 226 provides an overall framework for TM in MPLS. 228 In [8], RSVP is used to setup ERs and reserve bandwidth. However, in 229 [5], the LDP is used to setup the ER and to reserve bandwidth for the 230 LSPs. 232 This Section defines the necessary Traffic Management building block 233 for providing CoS support in MPLS. In addition, it extends the 234 procedure defined in [5] by proposing a simple but effective Label 235 Switched Path Admission Control Mechanism that allows for high 236 statistical multiplexing gain while providing a bandwidth guarantee. 238 In order for MPLS to provide effective Class of Service (CoS) 239 differentiation and guarantees, a set of traffic management function 240 have to be implemented by the LSRs. These functions includes traffic 241 shaping, traffic policing, queuing and scheduling, and LSP admission 242 control. 244 Traffic shaping is the TM function invoked at the egress point of a 245 network to limit the rate of traffic down to a specific value. 246 Traffic shapers often have a buffer that absorbs traffic bursts 247 beyond the shaping rate. Traffic shaping ensure that the outgoing 248 traffic rate from LSR1 to LSR2 (shown in Figure 1) does not exceed 249 the bandwidth agreement between ISP1 and ISP2. This function is 250 usually needed at the boundary between two administrative domains 251 (e.g., between ISP1 and ISP2). 253 | | 254 LSR1 | LSR2 LSR3 | LSR4 255 +------+ | +------+ +------+ | +------+ 256 | | | | | | | | | | 257 | | | | | | | | | | 258 | S |---+-----| P A |---------| S |---+------| P | 259 | A | | | Q | | A | | | | 260 | Q | | | | | Q | | | | 261 | | | | | | | | | | 262 +------+ | +------+ +------+ | +------+ 263 | | 264 ISP 1 | ISP 2 | ISP 3 265 | | 266 | | 267 Boundary Boundary 269 Legend 271 S Shaping 272 P Policing 273 A Admission Control 274 Q Queuing and Scheduling 276 Figure 1. MPLS Traffic Management Strategy 278 Traffic policing is the TM function invoked at the ingress point of a 279 network to ensures that only the agreed upon traffic rate is allowed 280 to consume network resources. Traffic policing is invoked by a 281 network service provider to protect its network resources (e.g., 282 bandwidth) from traffic that exceeds the traffic contract. Traffic 283 policing ensure that the incoming traffic rate from LSR1 to LSR2 does 284 not exceed the bandwidth agreement between ISP1 and ISP2. This 285 function is usually needed at the boundary between two administrative 286 domains (e.g., between ISP1 and ISP2). 288 A queuing and scheduling system is required in order to provide 289 differentiated service levels. For instance three emission and four 290 discard priorities provide twelve different service levels. The 291 emission priorities affect the delay observed by the traffic. The 292 discard priority affects the loss observed by the traffic. Delay 293 sensitive traffic uses the higher emission priority queue than less 294 delay sensitive traffic. Loss sensitive traffic uses the higher 295 discard priority (last one to discard) than the less loss sensitive 296 traffic. A sample queuing and scheduling system is described in 297 Appendix B. 299 Traffic shaping, policing, and queuing and scheduling are functions 300 often developed in hardware so that they don't impact data traffic 301 throughput. Most well-designed ATM hardware includes all of these 302 function. Therefore, an MPLS implementation on Label-Controlled ATM 303 interface (LC-ATM), inherits these functions. 305 Admission control ensures that bandwidth guarantees are met. This 306 function is often implemented in software and invoked at LSP setup 307 time. This Internet Draft proposes a simple yet effective mechanism 308 to reserve bandwidth for Explicitly Routed Label Switched Paths. We 309 focus in Sections 3.1-3.2 on LSP admission control which is the 310 procedure used to decide if a request for an LSP can be accepted, 311 based on the network capacity and the attributes of both the 312 requested and the existing LSPs. LSRs must perform LSPAC during the 313 LSP setup process as part of providing bandwidth guarantee. 315 3.1 Bandwidth Management 317 An important aspect of SIN operation is bandwidth management. ATM 318 and MPLS traffic share the same network facilities. The support of 319 SIN requires that the interaction between ATM traffic and MPLS 320 traffic is handled carefully. 322 A multi-service ATM network provides strict bandwidth guarantees to 323 its connections. MPLS Label Switched Paths (LSPs) can also reserve 324 bandwidth through the Label Distribution Protocol as defined in [5]. 326 The bandwidth reservation issue can be resolved in various ways 327 through configuration at start-up time. The following configuration 328 options are possible: 330 - Hard partitioning between ATM and MPLS 331 The aggregate interface bandwidth is partitioned between 332 ATM and MPLS. Two bandwidth pools are created; one for ATM and 333 another for MPLS. Each pool is allocated a percentage of the 334 interface capacity. ATM makes its bandwidth reservations from the 335 ATM pool and MPLS makes its bandwidth reservations from the MPLS 336 pool. 338 The choice of the bandwidth pool boundary between ATM and MPLS 339 is a Network Engineering exercise that takes into account the 340 expected bandwidth requirement of ATM and MPLS. An over-booking 341 factor can also be introduced where the sum of the percentages 342 allocated to ATM and MPLS add to more than 100%. 344 - Full sharing between ATM and MPLS 345 A single bandwidth pool is kept for both MPLS and ATM per 346 interface. As ATM connections or MPLS LSPs are admitted the 347 available bandwidth in the pool gets decremented. 349 The concept of bandwidth pools can be extended to provide a bandwidth 350 pool per ATM service category and per MPLS class of service in both 351 configuration modes. 353 3.2 Bandwidth Reservation in LDP 355 In [5], the following Reservation (RES) object is defined in Section 356 4.4.4.12: 358 " 359 +----------------+-------+--------------------------+----------+ 360 | OBJECT | Type | Subtype(s) | Length | 361 +----------------+-------+--------------------------+----------+ 362 | RES | 0x0C | 0x01 Raw Bandwidth | Variable | 363 +----------------+-------+--------------------------+----------+ 365 SubType = 0x01 Raw Bandwidth 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | BW requirement | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 BW Requirement 375 Unsigned 32 bit integer representing the bandwidth, in units 376 of 64,000 bps, that must be reserved for the LSP at the LSR 377 identified in the ERNH Object that contains this Reservation 378 Object." 380 There is no clear indication on what the value of the BW Requirement 381 field in the RES object should be. 383 Using a similar terminology to the one used in [9], we define a 384 connection's traffic characteristics as follows: 386 - R: peak rate, 387 - b: burst size, 388 - r: average rate 390 The BW requirement can be set to the peak rate R, average rate r, 391 or to an equivalent rate (e) of the LSP. Setting the BW requirement 392 to R of the LSP that has an On/Off traffic profile results in more 393 bandwidth reserved than actually needed. However, setting the BW 394 Requirement field to the r would result in high packet loss. 396 Therefore, in order to determine the BW Requirement field, it is 397 necessary to compute an equivalent rate of the Label Switched Path 398 (LSP). The computation of this rate needs to ensure two objectives 399 simultaneously: 401 1) Bandwidth guarantees; and 402 2) Efficient network resource utilization. 404 There are two ways of making the bandwidth reservation through LDP. 405 In the first option, the equivalent bandwidth is computed only once 406 at the LSR originating the ERLSP based on the traffic characteristics 407 (R, r, and b) of the LSP. The value e is then carried by LDP in the 408 RES object to inform the LSRs along the LSP of the bandwidth 409 requirement. The second option is to extend LDP to carry all three 410 traffic parameters and expect each LSR along the path to make its own 411 computation of the required bandwidth for the given LSP. 413 An extension to the current LDP specification [5] would be required 414 to support option 2 and to allow for the signaling of more bandwidth 415 parameters (R, r, and b) to more accurately characterize the 416 bandwidth requirements of an LSP. 418 Appendix A describes an example of an algorithm for computing e. 420 3.3 Queuing and Scheduling 422 ATM provides strict QoS guarantees. Hence, MPLS traffic should not 423 interfere with ATM traffic in any way that affect its QoS guarantees. 424 In addition, when MPLS provides bandwidth reservation and guarantees, 425 it is necessary to ensure that native ATM traffic does not interfere 426 with MPLS. 428 Bandwidth management presented in Section 3 works at the reservation 429 level. However, nodal-mechanisms of each LSR or ATM switch have to be 430 setup such that the QoS guarantees of ATM and MPLS are both met. 432 The nodal-mechanisms need to ensure that each service stays within 433 its bandwidth allocation limits. Traffic shaping and policing are 434 necessary to limit the throughput of each of the ATM and MPLS 435 services to the contracted values. 437 In addition, loss and delay guarantees for both ATM and MPLS have to 438 be met. This requires a careful mapping of ATM service categories and 439 of MPLS Classes of Service on the shared queuing and scheduling 440 system. 442 Appendix B describes a Multi-Priority System (MPS) presented as an 443 example of a queuing and scheduling mechanism and the mapping of MPLS 444 COSs and ATM service categories to the MPS. 446 3.4 Alignment with the DS-byte 448 The Diff-Serv model indicates that traffic conditioning is done at 449 the edge of the network. A codepoint is assigned to define the 450 behavior aggregate of the packet. Within the core, packets are 451 forwarded based on the PHB associated with the DS codepoint. However, 452 when going over an MPLS network where the underlying infrastructure 453 is ATM, the DS codepoint is not accessible to the hardware making the 454 forward decision. Therefore, a mapping between the DS codepoint and 455 an MPLS LSP that would provide the same PHB is required as packets 456 enter the MPLS domain. This means that multiple LSPs are established 457 for a given FEC to accommodate the various DS codepoints. 459 Currently, only two PHBs are proposed; the DE and the EF PHBs. The 460 [9] draft indicates that the mapping from the DS-byte codepoint to 461 the behavior MUST be configurable. Since in an MPLS domain running on 462 ATM, the mapping from the DS-codepoint to the LSP is only feasible on 463 the edge of the MPLS domain, the mapping has to also be configurable. 465 The DS-byte includes an in/out bit that indicates whether the packet 466 is within its contracted rate or not. Setting this bit to 'out' means 467 that under congestion, this packet should be discarded before packet 468 that have the bit set to 'in'. The in/out bit in the DS-byte is 469 similar to the CLP bit in ATM cells. Therefore, as part of the 470 mapping function from the DS-byte codepoint to an LSP with a given 471 priority, the In/Out bit should be mapped to the CLP bit of all the 472 cells resulting from the segmentation of the frame. 474 When going from an MPLS-ATM domain to a Diff-Serv domain, a mapping 475 is also required from the various LSPs to a set of codepoints. In 476 addition, if the CLP bit of any cells of a frame are set, then the 477 "Out" bit needs to be set accordingly. 479 4. Processing Capacity 481 When running in SIN mode, two routing and control stacks will reside 482 on the same nodes. ATM requires its signaling, and routing (IISP or 483 PNNI) software and topology database. MPLS requires its signaling 484 (LDP) and IP routing (RIP, OSPF, or BGP) software and topology 485 database. 487 Therefore, SIN operation requires that nodal processing capacity 488 (CPU, and memory) is adequate to simultaneously handle ATM and MPLS. 490 5. Summary 492 Ships in the night operation support is a required element in MPLS 493 [1]. This document highlights the requirements for SIN operation in 494 MPLS. Solutions are proposed to carefully share various resources 495 including VPI.VCI space, bandwidth, queuing and scheduling, and 496 processing capacity. 498 The traffic management building blocks that are necessary in order 499 for MPLS to provide CoS differentiation and guarantees are 500 identified. It proposed a simple yet effective mechanism to compute 501 the Equivalent Rate (e) of an Explicitly Routed Label Switched Path 502 to be signaled in the LDP RES object. The e computation allows for 503 high network bandwidth utilization while minimizing packet loss. An 504 admission control mechanism is described based on the e computation. 506 6. Security Considerations 508 Security issues are not discussed in this draft. 510 7. Acknowledgement 512 The authors would like to acknowledge the valuable comments of Pasi 513 Vaananen, Osama Aboul-Magd, Ken Hayward, and Don Fedyk. In addition, 514 recent MPLS Working Group discussions helped shape some sections of 515 this draft. 517 8. References 519 [1] R. Callon, et. al., "A Framework for Multiprotocol Label 520 Switching", draft-ietf-mpls-framework-02.txt, November 21, 1997. 522 [2] B. Davie, et. al., "Use of Label Switching With ATM", draft- 523 davie-mpls-atm-01.txt, July 1998. 525 [3] Ken-ichi Nagami, et. al., "VCID Notification over ATM link", 526 , March 1998. 528 [4] M. Suzuki, "The Assignment of the Information Field and Protocol 529 Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user 530 Signaling for the Internet Protocol", , June 1998. 533 [5] Anderson, et. al., "Label Distribution Protocol", draft-mpls- 534 ldp-00.txt, March 1998. 536 [6] "Integrated Local Management Interface (ILMI) Specification 537 Version 4", The ATM Forum technical committee, af-ilmi-0065.000, July 538 1996. 540 [7] P. Vaananen, et. al., "Framework for Traffic Management in MPLS 541 Networks", , March 1998. 543 [8] B. Davie, et. al., "Use of Label Switching With RSVP", , March 1998. 546 [9] Y. Bernet, et. al., "A Framework for Differentiated Services", 547 , May 1998. 549 9. Authors' Addresses 551 Bilel Jamoussi 552 Nortel (Northern Telecom), Ltd. 553 PO Box 3511 Station C 554 Ottawa ON K1Y 4H7 555 Canada 557 EMail: jamoussi@nortel.ca 559 Nancy Feldman 560 IBM Corp. 561 17 Skyline Drive 562 Hawthorne NY 10532 563 Phone: 914-784-3254 565 EMail: nkf@us.ibm.com 567 Loa Andersson 568 Bay Networks Inc. 569 3 Federal Street 570 Billerica, MA 01821 572 EMail: andersson@baynetworks.com 574 Appendix A Example Equivalent Rate Computation 576 The LSP admission problem is to find a nominal rate, called the 577 equivalent rate (e), for each connection so that 578 the system meets the specified performance objectives. 579 This condition would be achieved as long as the sum of the e 580 values of the accepted LSPs does not exceed the capacity of 581 the designated link. 583 If the number of admitted LSPs exceeds the number indicated by 584 the bound, then the packet loss will likely exceed the required 585 target. However, if the number of admitted calls is less than this bound, 586 then link bandwidth is wasted. 588 The estimate of e is computed by taking the average of the minimum and 589 maximum number of LSPs that can be supported by the link. 591 The minimum number of LSPs, min, that can be admitted without 592 introducing any nodal loss or delay is obtained such that the 593 sum of the peak rates (R) is less than the link rate 594 (L) (min * R < L). Hence min=L/R. 596 The maximum number of connections, max, 597 is obtained when the sum of the average rates (r=A*R), 598 where A is the source activity (A=r/R), exceeds the 599 link rate (R * max < L), and there is sustained congestion. 600 Hence, max = L / (A*R). When dividing the link rate by the average 601 of min and max, we obtain the equivalent rate (e), given by (EQ1). 603 e = R * [(2*A) / (1+A)] (EQ 1) 605 Note that the link rate L simplifies in the EQ 1 and is no longer 606 needed in the computation of e. 608 After computing (EQ 1), only once per LSP, the resulting e is signaled 609 in the LDP message establishing the LSP. e is compared to the Available 610 Rate (AvR) value for each hop (link) as follows: 612 if (e < AvR) 613 accept the LSP; 614 else 615 reject the LSP; 617 Appendix B Example of ATM Service Categories and MPLS COS Mappings 619 In this appendix, an example of how ATM and MPLS can be 620 mapped in a multi-priority system is presented. 622 Most well designed ATM hardware provides a way of differentiating the 623 quality of service received by the various ATM 624 service categories (CBR, VBR, UBR, etc.) through various queuing and 625 scheduling techniques. 627 In order to offer various delay and loss guarantees, ATM hardware often 628 uses multiple emission and discard priorities. Let's say we have 3 629 emission and 4 discard priorities. This MPS provides 12 different 630 qualities of service as shown in Figure 2. Traffic is emitted in the 631 order from E1 to E3. Therefore E1 has the lowest relative delay and E3 632 the highest. Under congestion, traffic is discard in the order from D4 633 to D1. Therefore, D1 has the lowest relative packet loss and D4 the 634 highest. 636 Emission 637 Priority 639 +-------------------------------------------+ ^ 640 | | | CBR | Control | E1 641 | | | | | 642 +-------------------------------------------+ 643 +-------------------------------------------+ 644 | | CoS 2 | rt-VBR | Control | E2 645 | | | | | 646 +-------------------------------------------+ 647 +-------------------------------------------+ 648 | UBR | nrt-VBR | | Control | E3 649 | CoS 0 | CoS 1 | | | 650 +-------------------------------------------+ 651 D4 D3 D2 D1 653 Discard Priority 655 Figure 2 Multi-Priority System (MPS) 657 Let's consider the open-loop ATM service categories (CBR, rt-VBR, 658 nrt-VBR, and UBR). For MPLS, we define three different Classes of 659 Service. 661 CoS 0 Best Effort 662 CoS 1 Low Loss Guarantee 663 CoS 2 Low Delay Guarantee 665 Figure 2 also shows the mapping from the ATM service categories to the 666 MPS as well as the mapping of MPLS CoSs to MPS. CoS 0 and UBR have a 667 similar definition ("best effort"). Hence, they share the same emission 668 and discard priority (the lowest). CoS 1 and nrt-VBR are both targeted 669 for low loss guarantee but do not care too much about delay. Therefore, 670 they are mapped to the E3/D3 slot. CoS 2 and rt-VBR require Low delay 671 guarantee. Hence, they are mapped to a higher emission priority than 672 CoS 0/ CoS 1. In order to provide rt-VBR with slightly better loss 673 guarantee than CoS 2, rt-VBR is mapped to a higher discard priority 674 (D2). Finally, CBR requires the best low delay and low loss 675 guarantees. Hence it is mapped to the highest emission and discard 676 priority. 678 Network control traffic is in the case of ATM the signaling, ILMI, and 679 RCC channels and in the case of MPLS the LDP channel etc.