idnits 2.17.1 draft-stdenis-ms-over-mpls-00.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? ** 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. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Nov 2000) is 8563 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '2' is mentioned on line 81, but not defined -- Looks like a reference, but probably isn't: '8-15' on line 528 -- Looks like a reference, but probably isn't: '0-7' on line 529 == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-02 Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force B. St-Denis, D. Fedyk 2 (Nortel Networks) 4 A. Bhatnagar, A. Siddiqui 5 (Cable and Wireless) 7 R. Hartani, T. So 8 (Caspian Networks) 10 Internet Draft 11 Document: Nov 2000 12 Category: Informational 14 Multi-service over MPLS 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026 [1]. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. Internet-Drafts are draft documents valid for a maximum of 25 six months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- Drafts 27 as reference material or to cite them other than as "work in 28 progress." 29 The list of current Internet-Drafts can be accessed at 30 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 Abstract 36 This document describes a generalized approach to carrying Multi- 37 service protocol data units (PDUs) over an MPLS Network. This 38 proposal defines standard MPLS encapsulations that support permanent 39 virtual circuit (PVC) and switch virtual circuit (SVC) networking. 40 The goal of this draft is to provide a framework that allows an MPLS 41 network to support a range of services from simple circuit emulation 42 services, to complete network inter-working. There are two distinct 43 aspects to these services: the data plane and the control plane. The 44 data plane must be defined to support nailed-up and switched 45 services. This architecture covers the data plane but not the 46 complete procedures for the control plane. The control plane is only 47 defined from a nailed up perspective. The control plane for dynamic 48 services maybe supported by other signaling protocols such as PNNI. 49 Non MPLS signaling is not covered by this draft. 51 St. Denis Informational _ Expires May 2001 1 52 Table of Contents 54 1. Introduction 55 2. Requirements 56 3. Framework Overview 57 3.1 Transport Label Details 58 3.2 Service Label Details 59 3.3 Multi-service Specific layer 60 4. Service Specifics 61 4.1 ATM Framework Requirements 62 4.1.1 ATM Service Specific Encoding 63 4.1.2 ATM VC Service Specific Encoding 64 4.1.3 ATM VP Service Specific Encoding 65 4.1.3.2 ATM VP Service Specific Encoding 66 4.2 Frame Relay Framework Requirements 67 4.2.1 Frame Relay Service Specific Encoding 68 4.3 Circuit Emulation Framework Requirements (CES) 69 4.3.1 CES Requirements 70 5. Signaling 71 5.1 Examples of Signaling Options 72 5.2 ATM Switched Services 73 6. Security Considerations 74 7. References 75 8. Acknowledgments 76 9. Author's Addresses 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC-2119 [2]. 82 1. Introduction 84 MPLS has the potential to reduce the complexity of service provider 85 infrastructures by allowing virtually any existing digital service 86 to be supported over a single networking infrastructure. However, 87 many service providers have legacy network and Operational Support 88 System (OSS) capabilities to support these existing service 89 offerings. The benefit of MPLS to this type of network operator is 90 as a common core transport for multiple existing legacy networks, 91 not as a unifying control plane architecture for all services. 93 MPLS as a common transport infrastructure provides the ability to 94 transparently carry existing networking systems and the evolution to 95 a single networking core. The benefit of this model to the service 96 provider is threefold: 97 - Leverage of the existing systems and services with increased 98 capacity from an MPLS enabled core. 99 - Existing network operational processes and procedures used to 100 maintain the legacy services are preserved. 101 - The common MPLS network infrastructure is used to support both the 102 core capacity requirements of legacy networks and the requirements 103 of new services which are supported natively over the MPLS network. 105 St-Denis Informational-Expires May 2001 2 106 The requirements for legacy service network operation over MPLS are 107 more comprehensive than simple PDU encapsulation. This is a 108 different approach than in some earlier drafts such as [1]. In 109 addition to the service attributes, the existing network operational 110 capabilities must also be preserved across the MPLS infrastructure. 112 2. Requirements 114 This section defines the architectural framework for support of 115 multiple services on MPLS. The framework drives the requirements to 116 support generic network behaviors required by multi-service 117 networks. However, while it does define requirements, the 118 architectural framework also allows independence in the MPLS 119 implementation used to support specific legacy services or networks. 121 The following requirements describe the set of information that is 122 required to enable preservation of legacy service and networking 123 attributes across an MPLS infrastructure: 125 - Payload types MUST be transparent so that none of the service 126 information is lost within the MPLS Network. 128 - The capabilities of the service MUST be specified by signaling, 129 provisioning, or a combination of the two techniques. By specifying 130 modes and parameters that are expected to be constants during a 131 flow, the requirements for including this information in a data 132 header are relaxed. 134 - A consistent self-describing format for all services encapsulated 135 in MPLS Multi-protocol format MUST be available. This will allow new 136 formats to be added at any time in the future. 138 - Segmentation and Re-assembly SHOULD be supported to ensure that 139 services are not limited by the MTU size of the MPLS network. Cell 140 concatenation and frame fragmentation are well understood 141 capabilities, which SHOULD be used to ensure that all service types, 142 may be transported across an MPLS network. 144 - The MPLS network SHOULD support order preservation. The network 145 SHOULD have the option to ensure that data exits the network in the 146 order in which it arrived, on a per service channel basis. If order 147 preservation is not required, then it can be omitted and the 148 bandwidth and processing can be saved. 150 - Service endpoints of the MPLS network SHOULD be as flexible as 151 possible, to allow for different behaviors on the edges of the 152 network. For example, a receiver may drop `out of order' frames when 153 sequencing is enabled or ignore the sequencing information 154 altogether. 156 3. Framework Overview 158 St-Denis Informational-Expires May 2001 3 159 The architecture for Multi-service over MPLS must provide for a 160 flexible set of label encapsulations to satisfy both aggregation and 161 non-aggregation of services. Services in this context are 162 traditional data services such as ATM and Frame Relay. Service 163 connections are instances of a session over one of these services 164 such as ATM VCs and Frame Relay connections. The intent is to extend 165 MPLS for services other than IP. In order to facilitate this, a 166 flexible label-stacking format has been adopted. The format is based 167 on standard MPLS label(s) and a service specific shim. To describe 168 this scheme two categories of labels have been defined, which 169 correspond to two layers Service labels and Transport labels. 171 Figure 1 illustrates the generic encapsulation format. Note that 172 this format uses a service specific "shim" between the MPLS label 173 and the payload so it can work on any MPLS network. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 / Transport Label(s) optional / 179 / / 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Service Label | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Multi-service Specific Layer (one or more octets) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Payload | 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1 General Encapsulation format 191 The Service layer, represented by Service labels, encapsulates 192 single service instances. Typically, they require provisioning or 193 signaling or a combination of both to establish the LSP. A service 194 may use a Service Label as the only label encapsulation in the non- 195 aggregated mode. 197 The Transport Layer, represented by Transport labels, provides 198 aggregation of several service instances between end points of a 199 transport tunnel. A transport label is the outer stacked label(s) 200 that are used to forward to the destination. Transport labels are 201 optional; in other words, point to point non-aggregate Service 202 labels can also be used. 204 Another term that is useful for categorizing the functions of Multi- 205 service switches is the concept of a label edge router (LER). A 206 Multi-service LER has to support the functions of the service and 207 the conversion to MPLS encapsulation. Any label switch router (LSR) 208 can transport the packets once they have been encapsulated. This is 210 St-Denis Informational-Expires May 2001 4 211 analogous to IP where an IP switch can become an IP LER so it 212 follows that a Multi-service switch can be a Multi-service LER. 214 +-------+ +------+ +------+ +-------+ 215 IP---|Multi- | | MPLS | | MPLS | |Multi- |---IP 216 ATM--|Service|------| LSR |------| LSR |------|Service|--ATM 217 FR---|LER | | | | | |LER |---FR 218 CES--| | | | | | | |--CES 219 +-------+ +------+ +------+ +-------+ 221 Figure 2 Multi-Service Label Edge Routers 223 3.1 Transport Label Details 225 Transport labels are simply MPLS labels or label stacks that are 226 part of a transport Label switched path (LSP). These are optional as 227 mentioned earlier. The most common use of a transport label is to 228 aggregate a set of service LSPs, on an explicit path, between a pair 229 of nodes in the network. 231 A transport label can also be represented as a Forwarding Adjacency 232 (FA) with a set of attributes. The transport label could be 233 advertised to the IGP or it could remain opaque to the IGP and local 234 to the LSP head end node. 236 Transport labels may be for any flavor of LSP: control driven, point 237 to point, merged or explicitly routed. How the transport labels are 238 constructed is not explicitly specified by the framework. Transport 239 tunnels would likely be engineered when trying to aggregate QoS 240 applications with similar traffic requirements. A transport label 241 may have bandwidth allocation for the whole tunnel and as a result 242 connection admission control may be performed on the tunnel when it 243 is established. Service labels can allocate bandwidth out of this 244 transport tunnels' allocation but how this is achieved is a local 245 issue not covered by the framework. 247 3.2 Service Label Details 249 Service labels represent labels that have a one to one 250 correspondence with a service connection. Service labels have two 251 modes of operation aggregated and non-aggregated. 253 Non-aggregated Service labels can be formed from any type of LSP. 254 Non-aggregated Service labels do not have a transport label. The 255 service label has a service connection associated with it, which can 256 be nailed up or configured hop by hop. The service connection may 257 also be configured at the ends and signaled by MPLS (see the 258 signaling section). 260 St-Denis Informational-Expires May 2001 5 261 Aggregated Service Labels are always associated with co-located 262 Transport labels and consequently may be simpler than non-aggregated 263 service labels. Aggregated service labels may be configured on the 264 ends points when nailed up over a Transport LSP that extends 265 multiple hops. Aggregated service labels can also have signaling 266 associated with them. 268 A service label MAY have traffic parameters associated with the LER. 269 If the service label is tunneled in a Transport label, the service 270 label MAY reserve bandwidth from the transport labels' bandwidth 271 allocation. As mentioned for Transport labels, this is outside the 272 scope of the framework. 274 3.3 Multi-service Specific layer 276 This header contains service specific information. Each service has 277 a defined encoding for this layer. All services share a common 278 format. 280 This header is a variable length header depending on the service and 281 the options on each LSP. 283 0 1 2 3 4 5 6 7 284 +------+------+------+------+------+------+------+------+ 285 | Service Specific Part | EXT | 286 +------+------+------+------+------+------+------+------+ 287 | Sequence Number [8:13] | BOM | EOM | 288 +------+------+------+------+------+------+------+------+ 289 | Sequence Number [0:7] | 290 +------+------+------+------+------+------+------+------+ 291 / Optional Extra Service Information / 292 +------+------+------+------+------+------+------+------+ 293 / Payload / 294 / / 295 +------+------+------+------+------+------+------+------+ 297 Figure 3 Multi-service Specific Layer 299 The Multi-service specific information is 8 bits that is specific to 300 each service type. A common bit 7 is an extension bit (EXT) that 301 specifies a 2 octet extension header. The service specific part is 302 specified for each service. 304 The extension header is used for packet ordering, segmentation, and 305 fragmentation. The extension header contains a beginning of frame 306 marker (BOM) and an end of frame marker (EOM) which are used if this 307 data has been fragmented. If the BOM and EOM are set to one then the 308 frame has not been fragmented. 310 St-Denis Informational-Expires May 2001 6 311 Sequence numbers are useful for ordering and also useful detecting 312 loss in the network. This is important for circuit emulation types 313 of service that may not have their own sequencing. 315 The Optional extra service field is available for further 316 information if the 7 bit service specific part is not sufficient. 318 4. Service Specifics 320 4.1 ATM Framework Requirements 322 1) The ability to map an ATM connection to an MPLS LSP. 324 2) Support for both VC and VP ATM Connections. 326 3) The ability to transparently carry ATM User payload across an 327 MPLS network. 329 4) The ability to transparently carry ATM Network Payload across an 330 MPLS network. For Example: 331 a) OAM cells 332 b) PM cells 334 5) The ability to transparently carry both ATM User and Network 335 payload across MPLS network on the same MPLS Service LSP. 337 6) The ability to carry ATM across the MPLS core efficiently for 338 both bandwidth efficiency on the links and for performance (i.e: 339 packet/sec) for the Core MPLS LSRs. This MAY imply the following: 340 a) Reassembling AAL5 frames before going in the MPLS Network 341 b) Segmenting AAL5 frame when exiting MPLS Network. Added 342 bandwidth efficiency can be gained by: 343 i) Optionally/Dynamically not carrying AAL5 Trailer. 344 ii) Optionally/Dynamically not carrying AAL5 Padding. 345 c) Concatenation of ATM cells (for example: Grouping a 346 collection of ATM cells on a single ATM connection). 348 7) When PM cells are transported then the following requirements are 349 a MUST: 350 a) The Cells must be ordered. (for example: ATM User Cells and 351 ATM Network Cells cannot be reordered) 352 b) The entire ATM User Payload must be carried. 354 8) When PM cells and Efficient ATM Transport (for example: AAL5 355 reassembly or concatenation cells) are transported, then following 356 requirements are a MUST: 357 a) There must be no increased delay due to reassembly (for 358 example: Don't wait for entire frame to be reassembled if a PM 359 Cell arrives. PM Cells must cause the reassembly engine to 360 send what it has currently reassembled as soon as a PM cell 361 arrives, followed immediately by the PM Cell. 363 St-Denis Informational-Expires May 2001 7 364 b) The statement a) above implies that Frame Segmentation for 365 AAL5 reassembly MUST be supported. 366 c) When exiting the MPLS Network, AAL5 Padding and Trailer 367 information must be reconstructed identically to how it looked 368 before entering MPLS Network. (due to requirement 7b). 370 4.1.1 ATM Service Specific Encoding 372 In order to accommodate the various modes of ATM cell formats the 373 service types are broken into VC and VP modes of services. Each mode 374 can be mixed on the same transport header but they will be described 375 individually. 377 4.1.2 ATM VC Service Specific Encoding 379 This service comprises of an individual ATM VC. The cell format of 380 this encapsulation will be described first. 382 0 1 2 3 4 5 6 7 383 +------+------+------+------+------+------+------+------+ 384 / Service Label / 385 +------+------+------+------+------+------+------+------+ 386 | CLP | PTI |Single| Cell | VCIP | EXT | <-- 387 +------+------+------+------+------+------+------+------+ 388 | Sequence Number [8:13] | 1 | 1 | 389 +------+------+------+------+------+------+------+------+ 390 | Sequence Number [0:7] | 391 +------+------+------+------+------+------+------+------+ 392 / Payload / 393 / / 394 +------+------+------+------+------+------+------+------+ 396 Figure 4 ATM VC Multi-service Specific Field 398 The CLP bit carries the CLP for the ATM cell. This information is 399 copied from the cell when the cell is encapsulated. The network MAY 400 use this bit directly to discard frames when buffers on queues 401 become large. This encoding MAY be encoded in the EXP bits of the 402 service label. 404 The PTI bits are the ATM Payload Type Indication bits. These bits 405 carry the same meaning as the ATM encoding. 407 The Single/Concatenation indication indicates whether this is a 408 single cell or a set of concatenated cells. Cell concatenation 409 allows cells to be grouped together to allow more efficient 410 transport. When cells are concatenated, each cell in the payload is 411 48 bytes in length. Cells can only be concatenated when all the 412 other fields are identical. 414 St-Denis Informational-Expires May 2001 8 415 The Cell/Frame indication indicates whether this is a single cell or 416 that it is a frame which has been reassembled. When set to 0 it 417 indicates a cell. The frame encoding is described below. 419 The RES bit is reserved for future expansion. 421 The EXT bit describes if the optional sequence number if carried. A 422 zero indicates no sequence number. 424 Since the cell format has a slightly different meaning when the 425 cells are concatenated together this format is outlined below. 427 0 1 2 3 4 5 6 7 428 +------+------+------+------+------+------+------+------+ 429 / Service Label / 430 +------+------+------+------+------+------+------+------+ 431 | CLP | PTI |B EFCI|Concat| Cell | VCIP | EXT |<-- 432 +------+------+------+------+------+------+------+------+ 433 | Sequence Number [8:13] | 1 | 1 | 434 +------+------+------+------+------+------+------+------+ 435 | Sequence Number [0:7] | 436 +------+------+------+------+------+------+------+------+ 437 / Cell / 438 / / 439 +------+------+------+------+------+------+------+------+ 440 Optional ATM Concatenation 441 +------+------+------+------+------+------+------+------+ 442 / Cell / 443 / / 444 +------+------+------+------+------+------+------+------+ 446 Figure 5 ATM VC Multi-service Specific Information Concatenated cell 447 format 449 Cell concatenation can only be performed on user cells. Therefore, 450 the bit 3 which indicates OAM cells is reused to carry the 451 concatenated EFCI. This bit is set by the network if there is 452 congestion when entering the MPLS Network. The MPLS network cannot 453 set this field since it does not know it is carrying ATM service. 454 This bit should be logically OR'ed into each cell when de- 455 concatenating. 457 Another option at the transmitting of the service tunnel is to 458 reassemble the cells into frames. The following is the format when 459 carrying frames. This format can improve the efficiency of carrying 460 frames over MPLS. This may be valuable when the speed of the ATM 461 interface is close to the speed of the MPLS interface for example. 463 0 1 2 3 4 5 6 7 464 +------+------+------+------+------+------+------+------+ 465 / Service Label / 467 St-Denis Informational-Expires May 2001 9 468 +------+------+------+------+------+------+------+------+ 469 | CLP | EFCI | FPTI |Frame | VCIP | EXT |<-- 470 +------+------+------+------+------+------+------+------+ 471 | Sequence Number [8:13] | BOM | EOM | 472 +------+------+------+------+------+------+------+------+ 473 | Sequence Number [0:7] | 474 +------+------+------+------+------+------+------+------+ 475 / Payload / 476 / / 477 +------+------+------+------+------+------+------+------+ 479 Figure 6 ATM VC Multi-service Specific Information Frame format 481 The Cell/Frame bit set to one indicates that this is a frame. 483 The FPTI bits are the frame PTI bits from the ATM cells. 484 The following list is the values and the meanings for the FPTI bits: 486 0: First segment of AAL5 Frame Payload in multiple of 48 octets 487 1: Full AAL5 Frame Payload (variable size) 488 2: Full AAL5 Frame Payload (variable size) with UU/ CPI, Same as 489 above with the addition of the UU and CPI AAL5 Trailer octets. 490 3: Full AAL5 Frame Payload with padding & UU/ CPI Entire AAL5 PDU 491 except for the AAL5 Trailers's 2 octet CRC 492 4: Middle segment of AAL5 Frame Payload in multiples of 48 octets. 493 5: Last segment of an AAL5 Frame Payload (variable size) plus the 4 494 octet AAL5 CRC and 2 octet Length field 495 6: Last segment of an AAL5 Frame Payload (variable size) with UU/ 496 CPI with the addition of the 8 octet AAL5 Trailer 497 7: Last segment of an AAL5 Frame Payload (variable size) with 498 padding & UU/ CPI Last segment of an AAL5 PDU in multiples of 48 499 octets. 501 The EFCI bit is the frame explicit forward congestion indication 502 bit. When concatenating cells the EFCI is set to the last ATM cell's 503 EFCI value. CLP is the logical OR of all the ATM cell's CLPs. 505 When segmenting the if the EFCI is set it SHOULD be logically OR'ed 506 into each cell EFCI. The same logic applies to the CLP bit. 508 4.1.3 ATM VP Service Specific Encoding 510 An ATM VP carries the same encoding as an ATM VC but the ATM VP can 511 carry multiple VCIs per VPI. Therefore, the ATM VP always carries an 512 extra field that has the value of the VCI. 514 4.1.3.2 ATM VP Service Specific Encoding 516 0 1 2 3 4 5 6 7 517 +------+------+------+------+------+------+------+------+ 519 St-Denis Informational-Expires May 2001 10 520 / Service Label / 521 +------+------+------+------+------+------+------+------+ 522 | CLP | // See VC specific Encodings // | VCIP | EXT | 523 +------+------+------+------+------+------+------+------+ 524 | Sequence Number [8:13] | BOM | EOM | 525 +------+------+------+------+------+------+------+------+ 526 | Sequence Number [0:7] | 527 +------+------+------+------+------+------+------+------+ 528 | VCI [8-15] |<-- 529 | VCI [0-7] |<-- 530 +------+------+------+------+------+------+------+------+ 531 / Payload / 532 / / 533 +------+------+------+------+------+------+------+------+ 534 Optional ATM Concatenation Header 535 +------+------+------+------+------+------+------+------+ 536 | CLP | PTI | RES | VCIP | RES |<-- 537 +------+------+------+------+------+------+------+------+ 538 | VCI [8:15] Optional |<-- 539 | VCI [0:7] |<-- 540 +------+------+------+------+------+------+------+------+ 541 / Cell / 542 / / 543 +------+------+------+------+------+------+------+------+ 545 Figure 7 ATM VP Optional Extra Service Information 547 Figure 7 illustrates the the placement of the VCI field when 548 included for a VP connection. 550 The VP encoding for concatenation is similar to the VC encoding with 551 the exception that the VCI has to be indicated for the Cells within 552 the payload. Each cell that is concatenated can be from the same VCI 553 or a different VCI in the case of a VP connection. 555 When concatenating cells if the same VCI is concatenated in adjacent 556 cells the VCI field may be omitted. The VCI Present (VCIP) field 557 indicates whether the VCI is present. 559 4.2 Frame Relay Framework Requirements 561 1) Frame Transport: MUST have the ability to carry both User and 562 Network traffic on the same Service LSP. MUST accommodate 563 variable length Frame Relay PDUs. 565 2) Connection Mapping: MUST support a one to one mapping of a Frame 566 Relay connection to a Service LSP. 568 St-Denis Informational-Expires May 2001 11 569 3) Frame Ordering: MUST support the reliable ordering of frames so 570 that frame order is always preserved across an end to end service 571 connection. SHOULD support a non-ordered mode of operation for 572 frames whose payload does not demand ordered service across the 573 end to end network. In this case, the requirement for sequence 574 number generation and checking is removed with appropriate 575 improvements in bandwidth efficiency and processing requirement. 576 MAY support the interleaving of ordered and non-ordered mode 577 within the same LSP for the efficient carriage of multiple 578 traffic types. 580 4) Frame Priority: MUST support the ability to map different 581 priority PVCs to appropriately engineered LSPs. SHOULD support 582 the ability to map the per-frame indication of discard 583 eligibility (DE) to the EXP bits of the service label and 584 transport label as appropriate. 586 5) Congestion Indication: Must support the transparent transport of 587 FECN (Forward Explicit Congestion Notification) and BECN 588 (Backward Explicit Congestion Notification) to allow end-to-end 589 congestion management. 591 6) PVC Status Management: MUST Support the mapping and transport of 592 PVC active and inactive indications. The support of end-to-end 593 connection integrity (continuity and performance) mechanisms 594 SHOULD be provided. 596 7) Traffic Management: Mapping of the following Frame Relay traffic 597 management parameters to the attributes of the Service LSP MAY be 598 provided: 600 a) CIR (Committed Information Rate) or throughput. 601 b) Bc (Committed burst size). 602 c) Be (Excess Burst Size). 603 d) Access Rate. 604 e) Maximum frame size. 606 4.2.1 Frame Relay Service Specific Encoding 608 St-Denis Informational-Expires May 2001 12 609 This service comprises an individual Frame Relay Connection. The 610 format of this encapsulation will be described first. 612 0 1 2 3 4 5 6 7 613 +------+------+------+------+------+------+------+------+ 614 / Service Label / 615 +------+------+------+------+------+------+------+------+ 616 | DE | C/R | BECN | FECN | OAM |Res(0)|Res(0)| EXT | 617 +------+------+------+------+------+------+------+------+ 618 | Sequence Number [8:13] | BOM | EOM | 619 +------+------+------+------+------+------+------+------+ 620 | Sequence Number [0:7] | 621 +------+------+------+------+------+------+------+------+ 622 / Payload / 623 / / 624 +------+------+------+------+------+------+------+------+ 626 Figure 8 FR Connection Multi-service Specific Field 628 The DE bit indicates the discard eligibility of the encapsulated 629 frame. This information is copied from the frame when the frame is 630 encapsulated. The network MAY use this bit directly to discard 631 frames when buffers on queues become large. This encoding MAY be 632 encoded in the EXP bits of the service label. 634 The C/R (command/response) bit is carried end-to-end without 635 modification. 637 FECN and BECN (Forward and Backward Explicit Congestion 638 Notification) bits are set when congestion is encountered. They are 639 never reset (to zero) by the network. 641 The EXT bit describes if the optional sequence number is carried. A 642 zero indicates no sequence number. 644 4.3 Circuit Emulation Framework Requirements (CES) 646 4.3.1 CES Requirements 648 1) CES Transport: MUST have the ability to carry both Payload and 649 Out-of-band information. MUST accommodate variable length PDUs. 650 Examples of out-of-band information are loop back signaling or A- 651 B bit signaling. 653 0 1 2 3 4 5 6 7 655 St-Denis Informational-Expires May 2001 13 656 +------+------+------+------+------+------+------+------+ 657 / Service Label / 658 +------+------+------+------+------+------+------+------+ 659 | | OAM | RES | EXT | 660 +------+------+------+------+------+------+------+------+ 661 | Sequence Number [8:13] | BOM | EOM | 662 +------+------+------+------+------+------+------+------+ 663 | Sequence Number [0:7] | 664 +------+------+------+------+------+------+------+------+ 665 / Payload / 666 / / 667 +------+------+------+------+------+------+------+------+ 669 Figure 9 CES Multi-service Specific Field 671 CES for low speed connections (DS0 to DS3) is different than for 672 high-speed connections (OC-1 to OC-192). For low speed CES, it 673 follows the same format as ATM's AAL1 standard. 675 5. Signaling 677 This section presents a functional description of the signaling 678 information required to support multi-service encapsulation over 679 MPLS. MPLS signaling specific formats and procedures are to be 680 included in a subsequent version of this draft. 682 Multi-service encapsulation over MPLS requires information to be 683 exchanged or coordinated by the service endpoints to ensure that 684 compatible capabilities are at each endpoint. This information may 685 be signaled using any of the traditional label distribution 686 protocols (LDP, CR-LDP, RSVP-TE) by simply enhancing the protocol(s) 687 with new TLVs/objects. The signaled information is to be processed 688 by the service endpoints (MS LERs) and be passed transparently by 689 each tandem LSR. 691 The following list indicates the information to be signaled by the 692 MS LERs (transmitter and receiver) during LSP establishment phase. 693 In its simplest form, the transmitter indicates the capability 694 required for a service, and the receiver accepts or rejects the 695 request. Optionally, a negotiation mechanism may be used in order to 696 have the transmitter and receiver agree on a capability set or 697 subset for a service. 699 St-Denis Informational-Expires May 2001 14 700 1) Service Type 702 The service type indicates the service requested. 704 Value Service Type 705 ----- ------------ 706 0 ATM 707 1 Frame Relay 708 2 CES 709 3 S-CES 710 4 Ethernet 711 5 VLAN 712 6 PPP 713 64-127 Vendor Specific 715 2)Service Sub Type 717 The service sub-type indicates the corresponding connection type of 718 the service. 720 For ATM service: 722 Value Service Sub-type 723 ----- ---------------- 724 0 VCC 725 1 VPC 727 For Frame Relay service: 729 Value Service Sub-type 730 ----- ---------------- 731 0 DLCI 733 For CES: 735 Value Service Sub-type 736 ----- ---------------- 737 0 DS-0 738 1 DS-1 739 2 DS-2 741 For S-CES: 743 Value Service Sub-type 744 ----- ---------------- 745 0 STS-1 746 1 STS-3c 747 2 STS-12c 748 3 STS-48c 750 St-Denis Informational-Expires May 2001 15 751 3) Format Indicators 753 Format indicators are required to request support for sequence 754 ordering and/or support for fragmentation. 756 Sequencing Flag 757 Set to 0 to indicate no sequence ordering 758 Set to 1 to indicate sequence ordering 760 Fragmentation Flag 761 Set to 0 to indicate no fragmentation 762 Set to 1 to indicate fragmentation support 764 When either of the format indicators are set, the service endpoints 765 must be able to support the MPLS extension header in the MSSL. 767 4)Service Specific Information 769 Service specific information is optionally signaled when a service 770 requires additional support for specific encoding of the PDUs. This 771 information must be agreed by both service endpoints. 773 For ATM, the service specific information has been defined as 774 follows: 776 ATM Encapsulation format 777 0 cell 778 1 frame 779 2 both 781 Cell Concatenation Indicator (only applicable for the cell 782 encapsulation format) 783 Set to 0, for single cell support 784 Set to 1, for support of concatenated cells 786 PM cell Indicator 787 Set to 0, for no support of PM cells 788 Set to 1, for support of PM cells 790 For CES, the service specific information is to be defined in a 791 subsequent draft. 793 5.1 Examples of Signaling Options 795 This section provides some examples of the signaling information to 796 be used for the different types of ATM services. 798 St-Denis Informational-Expires May 2001 16 799 ------------------------------------------------------------------ 800 Serv|Sub- | Format Indicator | SSI | Service 801 |Type |Seq. Flg| Frag.Flg| Encap |Conc | PM | Description 802 ------------------------------------------------------------------ 803 ATM | VCC | yes | yes | frame | no | no | aal5 VCC w/ frag 804 | | | | | | | & sequencing 805 ATM | VCC | no | no | frame | no | no | aal5 VCC w/o frag 806 ATM | VCC | yes | yes | frame | no | yes | aal5 VCC w/ frag 807 | | | | | | | & PM support 808 ATM | VCC | no | no | cell | yes | no | aal2 VCC concat 809 ATM | VCC | no | no | cell | no | no | aal2 VCC no conca 810 ATM | VPC | no | no | both | no | no | VPC 812 5.2 ATM Switched Services 814 In the case of ATM switched services over MPLS, ATM signaling MAY be 815 used to correlate the service information and to distribute the 816 service label. Note that this is only applicable for the aggregated 817 model, in which ATM switched services are tunneled across an MPLS 818 transport network. 820 The ATM service information is signaled using standard information 821 elements (e.g. AAL IE, ATM traffic descriptor IE, Connection 822 Identifier IE). The label information MAY be distributed via the GIT 823 IE in the Setup and Connect message. Procedures on how to handle 824 label distribution via ATM signaling are out of the scope of this 825 draft. 827 6. Security Considerations 829 This draft does not introduce any new security considerations to 830 MPLS. 832 7. References 834 [1] _Transport of Layer 2 Frames Over MPLS_, draft-martini- 835 l2circuit-trans-mpls-02.txt, L. Martini et al( work in progress ) 837 8. Acknowledgments 839 The authors would like to acknowledge the contributions to this work 840 by Sandra Ballarte, John Davies, Tim Pearson and Greg Wright. 842 9. Author's Addresses 844 St-Denis Informational-Expires May 2001 17 845 Bernie St-Denis Don Fedyk 846 Nortel Networks Nortel Networks 847 3500 Carling Avenue 600 Technology Park Drive 848 Nepean, Ontario Billerica, Massachusetts 01821 849 Canada. K2H 8E9 USA 850 Email: bernie@nortelnetworks.com Phone: (978) 288-3041 851 Email: dwfedyk@nortelnetworks.com 853 Aditya Bhatnagar Adeel Siddiqui 854 Cable & Wireless Cable & Wireless 855 11700 Plaza America Drive, 11700 Plaza America Drive, 856 10th Floor 10th Floor 857 Reston VA 20190 Reston VA 20190 858 USA USA 859 Aditya.Bhatnagar@cwusa.com Adeel.Siddiqui@cwusa.com 861 Riad Hartani Tricci So 862 Caspian Networks Caspian Networks 863 Address: 170 Baytech Drive, Address: 170 Baytech Drive, 864 San Jose, CA, U.S.A., 95134 San Jose, CA, U.S.A., 95134 865 Phone: 408-382-5216 Phone: 408-382-5588 866 Email: riad@caspiannetworks.com Email: tso@caspiannetworks.com 868 St-Denis Informational-Expires May 2001 18 869 Full Copyright Statement 871 "Copyright (C) The Internet Society 2000. All Rights Reserved. This 872 document and translations of it may be copied and furnished to 873 others, and derivative works that comment on or otherwise explain it 874 or assist in its implementation may be prepared, copied, published 875 and distributed, in whole or in part, without restriction of any 876 kind, provided that the above copyright notice and this paragraph 877 are included on all such copies and derivative works. However, this 878 document itself may not be modified in any way, such as by removing 879 the copyright notice or references to the Internet Society or other 880 Internet organizations, except as needed for the purpose of 881 developing Internet standards in which case the procedures for 882 copyrights defined in the Internet Standards process must be 883 followed, or as required to translate it into English. 885 The limited permissions granted above are perpetual and will not be 886 revoked by the Internet Society or its successors or assigns. 888 This document and the information contained herein is provided on an 889 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 890 ASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 891 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 892 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 893 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 895 St-Denis Informational-Expires May 2001 19