Internet Draft Internet Engineering Task Force B. St-Denis, D. Fedyk (Nortel Networks) A. Bhatnagar, A. Siddiqui (Cable and Wireless) R. Hartani, T. So (Caspian Networks) Internet Draft Document: <draft-stdenis-ms-over-mpls-00.txt> Nov 2000 Category: Informational Multi-service over MPLS Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a generalized approach to carrying Multi- service protocol data units (PDUs) over an MPLS Network. This proposal defines standard MPLS encapsulations that support permanent virtual circuit (PVC) and switch virtual circuit (SVC) networking. The goal of this draft is to provide a framework that allows an MPLS network to support a range of services from simple circuit emulation services, to complete network inter-working. There are two distinct aspects to these services: the data plane and the control plane. The data plane must be defined to support nailed-up and switched services. This architecture covers the data plane but not the complete procedures for the control plane. The control plane is only defined from a nailed up perspective. The control plane for dynamic services maybe supported by other signaling protocols such as PNNI. Non MPLS signaling is not covered by this draft. St. Denis Informational _ Expires May 2001 1 Multi-service over MPLS November 2000 Table of Contents 1. Introduction 2. Requirements 3. Framework Overview 3.1 Transport Label Details 3.2 Service Label Details 3.3 Multi-service Specific layer 4. Service Specifics 4.1 ATM Framework Requirements 4.1.1 ATM Service Specific Encoding 4.1.2 ATM VC Service Specific Encoding 4.1.3 ATM VP Service Specific Encoding 4.1.3.2 ATM VP Service Specific Encoding 4.2 Frame Relay Framework Requirements 4.2.1 Frame Relay Service Specific Encoding 4.3 Circuit Emulation Framework Requirements (CES) 4.3.1 CES Requirements 5. Signaling 5.1 Examples of Signaling Options 5.2 ATM Switched Services 6. Security Considerations 7. References 8. Acknowledgments 9. Author's Addresses The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 1. Introduction MPLS has the potential to reduce the complexity of service provider infrastructures by allowing virtually any existing digital service to be supported over a single networking infrastructure. However, many service providers have legacy network and Operational Support System (OSS) capabilities to support these existing service offerings. The benefit of MPLS to this type of network operator is as a common core transport for multiple existing legacy networks, not as a unifying control plane architecture for all services. MPLS as a common transport infrastructure provides the ability to transparently carry existing networking systems and the evolution to a single networking core. The benefit of this model to the service provider is threefold: - Leverage of the existing systems and services with increased capacity from an MPLS enabled core. - Existing network operational processes and procedures used to maintain the legacy services are preserved. - The common MPLS network infrastructure is used to support both the core capacity requirements of legacy networks and the requirements of new services which are supported natively over the MPLS network. St-Denis Informational-Expires May 2001 2 Multi-service over MPLS November 2000 The requirements for legacy service network operation over MPLS are more comprehensive than simple PDU encapsulation. This is a different approach than in some earlier drafts such as [1]. In addition to the service attributes, the existing network operational capabilities must also be preserved across the MPLS infrastructure. 2. Requirements This section defines the architectural framework for support of multiple services on MPLS. The framework drives the requirements to support generic network behaviors required by multi-service networks. However, while it does define requirements, the architectural framework also allows independence in the MPLS implementation used to support specific legacy services or networks. The following requirements describe the set of information that is required to enable preservation of legacy service and networking attributes across an MPLS infrastructure: - Payload types MUST be transparent so that none of the service information is lost within the MPLS Network. - The capabilities of the service MUST be specified by signaling, provisioning, or a combination of the two techniques. By specifying modes and parameters that are expected to be constants during a flow, the requirements for including this information in a data header are relaxed. - A consistent self-describing format for all services encapsulated in MPLS Multi-protocol format MUST be available. This will allow new formats to be added at any time in the future. - Segmentation and Re-assembly SHOULD be supported to ensure that services are not limited by the MTU size of the MPLS network. Cell concatenation and frame fragmentation are well understood capabilities, which SHOULD be used to ensure that all service types, may be transported across an MPLS network. - The MPLS network SHOULD support order preservation. The network SHOULD have the option to ensure that data exits the network in the order in which it arrived, on a per service channel basis. If order preservation is not required, then it can be omitted and the bandwidth and processing can be saved. - Service endpoints of the MPLS network SHOULD be as flexible as possible, to allow for different behaviors on the edges of the network. For example, a receiver may drop `out of order' frames when sequencing is enabled or ignore the sequencing information altogether. 3. Framework Overview St-Denis Informational-Expires May 2001 3 Multi-service over MPLS November 2000 The architecture for Multi-service over MPLS must provide for a flexible set of label encapsulations to satisfy both aggregation and non-aggregation of services. Services in this context are traditional data services such as ATM and Frame Relay. Service connections are instances of a session over one of these services such as ATM VCs and Frame Relay connections. The intent is to extend MPLS for services other than IP. In order to facilitate this, a flexible label-stacking format has been adopted. The format is based on standard MPLS label(s) and a service specific shim. To describe this scheme two categories of labels have been defined, which correspond to two layers Service labels and Transport labels. Figure 1 illustrates the generic encapsulation format. Note that this format uses a service specific "shim" between the MPLS label and the payload so it can work on any MPLS network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Transport Label(s) optional / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multi-service Specific Layer (one or more octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 General Encapsulation format The Service layer, represented by Service labels, encapsulates single service instances. Typically, they require provisioning or signaling or a combination of both to establish the LSP. A service may use a Service Label as the only label encapsulation in the non- aggregated mode. The Transport Layer, represented by Transport labels, provides aggregation of several service instances between end points of a transport tunnel. A transport label is the outer stacked label(s) that are used to forward to the destination. Transport labels are optional; in other words, point to point non-aggregate Service labels can also be used. Another term that is useful for categorizing the functions of Multi- service switches is the concept of a label edge router (LER). A Multi-service LER has to support the functions of the service and the conversion to MPLS encapsulation. Any label switch router (LSR) can transport the packets once they have been encapsulated. This is St-Denis Informational-Expires May 2001 4 Multi-service over MPLS November 2000 analogous to IP where an IP switch can become an IP LER so it follows that a Multi-service switch can be a Multi-service LER. +-------+ +------+ +------+ +-------+ IP---|Multi- | | MPLS | | MPLS | |Multi- |---IP ATM--|Service|------| LSR |------| LSR |------|Service|--ATM FR---|LER | | | | | |LER |---FR CES--| | | | | | | |--CES +-------+ +------+ +------+ +-------+ Figure 2 Multi-Service Label Edge Routers 3.1 Transport Label Details Transport labels are simply MPLS labels or label stacks that are part of a transport Label switched path (LSP). These are optional as mentioned earlier. The most common use of a transport label is to aggregate a set of service LSPs, on an explicit path, between a pair of nodes in the network. A transport label can also be represented as a Forwarding Adjacency (FA) with a set of attributes. The transport label could be advertised to the IGP or it could remain opaque to the IGP and local to the LSP head end node. Transport labels may be for any flavor of LSP: control driven, point to point, merged or explicitly routed. How the transport labels are constructed is not explicitly specified by the framework. Transport tunnels would likely be engineered when trying to aggregate QoS applications with similar traffic requirements. A transport label may have bandwidth allocation for the whole tunnel and as a result connection admission control may be performed on the tunnel when it is established. Service labels can allocate bandwidth out of this transport tunnels' allocation but how this is achieved is a local issue not covered by the framework. 3.2 Service Label Details Service labels represent labels that have a one to one correspondence with a service connection. Service labels have two modes of operation aggregated and non-aggregated. Non-aggregated Service labels can be formed from any type of LSP. Non-aggregated Service labels do not have a transport label. The service label has a service connection associated with it, which can be nailed up or configured hop by hop. The service connection may also be configured at the ends and signaled by MPLS (see the signaling section). St-Denis Informational-Expires May 2001 5 Multi-service over MPLS November 2000 Aggregated Service Labels are always associated with co-located Transport labels and consequently may be simpler than non-aggregated service labels. Aggregated service labels may be configured on the ends points when nailed up over a Transport LSP that extends multiple hops. Aggregated service labels can also have signaling associated with them. A service label MAY have traffic parameters associated with the LER. If the service label is tunneled in a Transport label, the service label MAY reserve bandwidth from the transport labels' bandwidth allocation. As mentioned for Transport labels, this is outside the scope of the framework. 3.3 Multi-service Specific layer This header contains service specific information. Each service has a defined encoding for this layer. All services share a common format. This header is a variable length header depending on the service and the options on each LSP. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | Service Specific Part | EXT | +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | BOM | EOM | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Optional Extra Service Information / +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 3 Multi-service Specific Layer The Multi-service specific information is 8 bits that is specific to each service type. A common bit 7 is an extension bit (EXT) that specifies a 2 octet extension header. The service specific part is specified for each service. The extension header is used for packet ordering, segmentation, and fragmentation. The extension header contains a beginning of frame marker (BOM) and an end of frame marker (EOM) which are used if this data has been fragmented. If the BOM and EOM are set to one then the frame has not been fragmented. St-Denis Informational-Expires May 2001 6 Multi-service over MPLS November 2000 Sequence numbers are useful for ordering and also useful detecting loss in the network. This is important for circuit emulation types of service that may not have their own sequencing. The Optional extra service field is available for further information if the 7 bit service specific part is not sufficient. 4. Service Specifics 4.1 ATM Framework Requirements 1) The ability to map an ATM connection to an MPLS LSP. 2) Support for both VC and VP ATM Connections. 3) The ability to transparently carry ATM User payload across an MPLS network. 4) The ability to transparently carry ATM Network Payload across an MPLS network. For Example: a) OAM cells b) PM cells 5) The ability to transparently carry both ATM User and Network payload across MPLS network on the same MPLS Service LSP. 6) The ability to carry ATM across the MPLS core efficiently for both bandwidth efficiency on the links and for performance (i.e: packet/sec) for the Core MPLS LSRs. This MAY imply the following: a) Reassembling AAL5 frames before going in the MPLS Network b) Segmenting AAL5 frame when exiting MPLS Network. Added bandwidth efficiency can be gained by: i) Optionally/Dynamically not carrying AAL5 Trailer. ii) Optionally/Dynamically not carrying AAL5 Padding. c) Concatenation of ATM cells (for example: Grouping a collection of ATM cells on a single ATM connection). 7) When PM cells are transported then the following requirements are a MUST: a) The Cells must be ordered. (for example: ATM User Cells and ATM Network Cells cannot be reordered) b) The entire ATM User Payload must be carried. 8) When PM cells and Efficient ATM Transport (for example: AAL5 reassembly or concatenation cells) are transported, then following requirements are a MUST: a) There must be no increased delay due to reassembly (for example: Don't wait for entire frame to be reassembled if a PM Cell arrives. PM Cells must cause the reassembly engine to send what it has currently reassembled as soon as a PM cell arrives, followed immediately by the PM Cell. St-Denis Informational-Expires May 2001 7 Multi-service over MPLS November 2000 b) The statement a) above implies that Frame Segmentation for AAL5 reassembly MUST be supported. c) When exiting the MPLS Network, AAL5 Padding and Trailer information must be reconstructed identically to how it looked before entering MPLS Network. (due to requirement 7b). 4.1.1 ATM Service Specific Encoding In order to accommodate the various modes of ATM cell formats the service types are broken into VC and VP modes of services. Each mode can be mixed on the same transport header but they will be described individually. 4.1.2 ATM VC Service Specific Encoding This service comprises of an individual ATM VC. The cell format of this encapsulation will be described first. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ / Service Label / +------+------+------+------+------+------+------+------+ | CLP | PTI |Single| Cell | VCIP | EXT | <-- +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | 1 | 1 | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 4 ATM VC Multi-service Specific Field The CLP bit carries the CLP for the ATM cell. This information is copied from the cell when the cell is encapsulated. The network MAY use this bit directly to discard frames when buffers on queues become large. This encoding MAY be encoded in the EXP bits of the service label. The PTI bits are the ATM Payload Type Indication bits. These bits carry the same meaning as the ATM encoding. The Single/Concatenation indication indicates whether this is a single cell or a set of concatenated cells. Cell concatenation allows cells to be grouped together to allow more efficient transport. When cells are concatenated, each cell in the payload is 48 bytes in length. Cells can only be concatenated when all the other fields are identical. St-Denis Informational-Expires May 2001 8 Multi-service over MPLS November 2000 The Cell/Frame indication indicates whether this is a single cell or that it is a frame which has been reassembled. When set to 0 it indicates a cell. The frame encoding is described below. The RES bit is reserved for future expansion. The EXT bit describes if the optional sequence number if carried. A zero indicates no sequence number. Since the cell format has a slightly different meaning when the cells are concatenated together this format is outlined below. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ / Service Label / +------+------+------+------+------+------+------+------+ | CLP | PTI |B EFCI|Concat| Cell | VCIP | EXT |<-- +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | 1 | 1 | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Cell / / / +------+------+------+------+------+------+------+------+ Optional ATM Concatenation +------+------+------+------+------+------+------+------+ / Cell / / / +------+------+------+------+------+------+------+------+ Figure 5 ATM VC Multi-service Specific Information Concatenated cell format Cell concatenation can only be performed on user cells. Therefore, the bit 3 which indicates OAM cells is reused to carry the concatenated EFCI. This bit is set by the network if there is congestion when entering the MPLS Network. The MPLS network cannot set this field since it does not know it is carrying ATM service. This bit should be logically OR'ed into each cell when de- concatenating. Another option at the transmitting of the service tunnel is to reassemble the cells into frames. The following is the format when carrying frames. This format can improve the efficiency of carrying frames over MPLS. This may be valuable when the speed of the ATM interface is close to the speed of the MPLS interface for example. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ / Service Label / St-Denis Informational-Expires May 2001 9 Multi-service over MPLS November 2000 +------+------+------+------+------+------+------+------+ | CLP | EFCI | FPTI |Frame | VCIP | EXT |<-- +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | BOM | EOM | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 6 ATM VC Multi-service Specific Information Frame format The Cell/Frame bit set to one indicates that this is a frame. The FPTI bits are the frame PTI bits from the ATM cells. The following list is the values and the meanings for the FPTI bits: 0: First segment of AAL5 Frame Payload in multiple of 48 octets 1: Full AAL5 Frame Payload (variable size) 2: Full AAL5 Frame Payload (variable size) with UU/ CPI, Same as above with the addition of the UU and CPI AAL5 Trailer octets. 3: Full AAL5 Frame Payload with padding & UU/ CPI Entire AAL5 PDU except for the AAL5 Trailers's 2 octet CRC 4: Middle segment of AAL5 Frame Payload in multiples of 48 octets. 5: Last segment of an AAL5 Frame Payload (variable size) plus the 4 octet AAL5 CRC and 2 octet Length field 6: Last segment of an AAL5 Frame Payload (variable size) with UU/ CPI with the addition of the 8 octet AAL5 Trailer 7: Last segment of an AAL5 Frame Payload (variable size) with padding & UU/ CPI Last segment of an AAL5 PDU in multiples of 48 octets. The EFCI bit is the frame explicit forward congestion indication bit. When concatenating cells the EFCI is set to the last ATM cell's EFCI value. CLP is the logical OR of all the ATM cell's CLPs. When segmenting the if the EFCI is set it SHOULD be logically OR'ed into each cell EFCI. The same logic applies to the CLP bit. 4.1.3 ATM VP Service Specific Encoding An ATM VP carries the same encoding as an ATM VC but the ATM VP can carry multiple VCIs per VPI. Therefore, the ATM VP always carries an extra field that has the value of the VCI. 4.1.3.2 ATM VP Service Specific Encoding 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ St-Denis Informational-Expires May 2001 10 Multi-service over MPLS November 2000 / Service Label / +------+------+------+------+------+------+------+------+ | CLP | // See VC specific Encodings // | VCIP | EXT | +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | BOM | EOM | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ | VCI [8-15] |<-- | VCI [0-7] |<-- +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Optional ATM Concatenation Header +------+------+------+------+------+------+------+------+ | CLP | PTI | RES | VCIP | RES |<-- +------+------+------+------+------+------+------+------+ | VCI [8:15] Optional |<-- | VCI [0:7] |<-- +------+------+------+------+------+------+------+------+ / Cell / / / +------+------+------+------+------+------+------+------+ Figure 7 ATM VP Optional Extra Service Information Figure 7 illustrates the the placement of the VCI field when included for a VP connection. The VP encoding for concatenation is similar to the VC encoding with the exception that the VCI has to be indicated for the Cells within the payload. Each cell that is concatenated can be from the same VCI or a different VCI in the case of a VP connection. When concatenating cells if the same VCI is concatenated in adjacent cells the VCI field may be omitted. The VCI Present (VCIP) field indicates whether the VCI is present. 4.2 Frame Relay Framework Requirements 1) Frame Transport: MUST have the ability to carry both User and Network traffic on the same Service LSP. MUST accommodate variable length Frame Relay PDUs. 2) Connection Mapping: MUST support a one to one mapping of a Frame Relay connection to a Service LSP. St-Denis Informational-Expires May 2001 11 Multi-service over MPLS November 2000 3) Frame Ordering: MUST support the reliable ordering of frames so that frame order is always preserved across an end to end service connection. SHOULD support a non-ordered mode of operation for frames whose payload does not demand ordered service across the end to end network. In this case, the requirement for sequence number generation and checking is removed with appropriate improvements in bandwidth efficiency and processing requirement. MAY support the interleaving of ordered and non-ordered mode within the same LSP for the efficient carriage of multiple traffic types. 4) Frame Priority: MUST support the ability to map different priority PVCs to appropriately engineered LSPs. SHOULD support the ability to map the per-frame indication of discard eligibility (DE) to the EXP bits of the service label and transport label as appropriate. 5) Congestion Indication: Must support the transparent transport of FECN (Forward Explicit Congestion Notification) and BECN (Backward Explicit Congestion Notification) to allow end-to-end congestion management. 6) PVC Status Management: MUST Support the mapping and transport of PVC active and inactive indications. The support of end-to-end connection integrity (continuity and performance) mechanisms SHOULD be provided. 7) Traffic Management: Mapping of the following Frame Relay traffic management parameters to the attributes of the Service LSP MAY be provided: a) CIR (Committed Information Rate) or throughput. b) Bc (Committed burst size). c) Be (Excess Burst Size). d) Access Rate. e) Maximum frame size. 4.2.1 Frame Relay Service Specific Encoding St-Denis Informational-Expires May 2001 12 Multi-service over MPLS November 2000 This service comprises an individual Frame Relay Connection. The format of this encapsulation will be described first. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ / Service Label / +------+------+------+------+------+------+------+------+ | DE | C/R | BECN | FECN | OAM |Res(0)|Res(0)| EXT | +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | BOM | EOM | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 8 FR Connection Multi-service Specific Field The DE bit indicates the discard eligibility of the encapsulated frame. This information is copied from the frame when the frame is encapsulated. The network MAY use this bit directly to discard frames when buffers on queues become large. This encoding MAY be encoded in the EXP bits of the service label. The C/R (command/response) bit is carried end-to-end without modification. FECN and BECN (Forward and Backward Explicit Congestion Notification) bits are set when congestion is encountered. They are never reset (to zero) by the network. The EXT bit describes if the optional sequence number is carried. A zero indicates no sequence number. 4.3 Circuit Emulation Framework Requirements (CES) 4.3.1 CES Requirements 1) CES Transport: MUST have the ability to carry both Payload and Out-of-band information. MUST accommodate variable length PDUs. Examples of out-of-band information are loop back signaling or A- B bit signaling. 0 1 2 3 4 5 6 7 St-Denis Informational-Expires May 2001 13 Multi-service over MPLS November 2000 +------+------+------+------+------+------+------+------+ / Service Label / +------+------+------+------+------+------+------+------+ | | OAM | RES | EXT | +------+------+------+------+------+------+------+------+ | Sequence Number [8:13] | BOM | EOM | +------+------+------+------+------+------+------+------+ | Sequence Number [0:7] | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 9 CES Multi-service Specific Field CES for low speed connections (DS0 to DS3) is different than for high-speed connections (OC-1 to OC-192). For low speed CES, it follows the same format as ATM's AAL1 standard. 5. Signaling This section presents a functional description of the signaling information required to support multi-service encapsulation over MPLS. MPLS signaling specific formats and procedures are to be included in a subsequent version of this draft. Multi-service encapsulation over MPLS requires information to be exchanged or coordinated by the service endpoints to ensure that compatible capabilities are at each endpoint. This information may be signaled using any of the traditional label distribution protocols (LDP, CR-LDP, RSVP-TE) by simply enhancing the protocol(s) with new TLVs/objects. The signaled information is to be processed by the service endpoints (MS LERs) and be passed transparently by each tandem LSR. The following list indicates the information to be signaled by the MS LERs (transmitter and receiver) during LSP establishment phase. In its simplest form, the transmitter indicates the capability required for a service, and the receiver accepts or rejects the request. Optionally, a negotiation mechanism may be used in order to have the transmitter and receiver agree on a capability set or subset for a service. St-Denis Informational-Expires May 2001 14 Multi-service over MPLS November 2000 1) Service Type The service type indicates the service requested. Value Service Type ----- ------------ 0 ATM 1 Frame Relay 2 CES 3 S-CES 4 Ethernet 5 VLAN 6 PPP 64-127 Vendor Specific 2)Service Sub Type The service sub-type indicates the corresponding connection type of the service. For ATM service: Value Service Sub-type ----- ---------------- 0 VCC 1 VPC For Frame Relay service: Value Service Sub-type ----- ---------------- 0 DLCI For CES: Value Service Sub-type ----- ---------------- 0 DS-0 1 DS-1 2 DS-2 For S-CES: Value Service Sub-type ----- ---------------- 0 STS-1 1 STS-3c 2 STS-12c 3 STS-48c St-Denis Informational-Expires May 2001 15 Multi-service over MPLS November 2000 3) Format Indicators Format indicators are required to request support for sequence ordering and/or support for fragmentation. Sequencing Flag Set to 0 to indicate no sequence ordering Set to 1 to indicate sequence ordering Fragmentation Flag Set to 0 to indicate no fragmentation Set to 1 to indicate fragmentation support When either of the format indicators are set, the service endpoints must be able to support the MPLS extension header in the MSSL. 4)Service Specific Information Service specific information is optionally signaled when a service requires additional support for specific encoding of the PDUs. This information must be agreed by both service endpoints. For ATM, the service specific information has been defined as follows: ATM Encapsulation format 0 cell 1 frame 2 both Cell Concatenation Indicator (only applicable for the cell encapsulation format) Set to 0, for single cell support Set to 1, for support of concatenated cells PM cell Indicator Set to 0, for no support of PM cells Set to 1, for support of PM cells For CES, the service specific information is to be defined in a subsequent draft. 5.1 Examples of Signaling Options This section provides some examples of the signaling information to be used for the different types of ATM services. St-Denis Informational-Expires May 2001 16 Multi-service over MPLS November 2000 ------------------------------------------------------------------ Serv|Sub- | Format Indicator | SSI | Service |Type |Seq. Flg| Frag.Flg| Encap |Conc | PM | Description ------------------------------------------------------------------ ATM | VCC | yes | yes | frame | no | no | aal5 VCC w/ frag | | | | | | | & sequencing ATM | VCC | no | no | frame | no | no | aal5 VCC w/o frag ATM | VCC | yes | yes | frame | no | yes | aal5 VCC w/ frag | | | | | | | & PM support ATM | VCC | no | no | cell | yes | no | aal2 VCC concat ATM | VCC | no | no | cell | no | no | aal2 VCC no conca ATM | VPC | no | no | both | no | no | VPC 5.2 ATM Switched Services In the case of ATM switched services over MPLS, ATM signaling MAY be used to correlate the service information and to distribute the service label. Note that this is only applicable for the aggregated model, in which ATM switched services are tunneled across an MPLS transport network. The ATM service information is signaled using standard information elements (e.g. AAL IE, ATM traffic descriptor IE, Connection Identifier IE). The label information MAY be distributed via the GIT IE in the Setup and Connect message. Procedures on how to handle label distribution via ATM signaling are out of the scope of this draft. 6. Security Considerations This draft does not introduce any new security considerations to MPLS. 7. References [1] _Transport of Layer 2 Frames Over MPLS_, draft-martini- l2circuit-trans-mpls-02.txt, L. Martini et al( work in progress ) 8. Acknowledgments The authors would like to acknowledge the contributions to this work by Sandra Ballarte, John Davies, Tim Pearson and Greg Wright. 9. Author's Addresses St-Denis Informational-Expires May 2001 17 Multi-service over MPLS November 2000 Bernie St-Denis Don Fedyk Nortel Networks Nortel Networks 3500 Carling Avenue 600 Technology Park Drive Nepean, Ontario Billerica, Massachusetts 01821 Canada. K2H 8E9 USA Email: bernie@nortelnetworks.com Phone: (978) 288-3041 Email: dwfedyk@nortelnetworks.com Aditya Bhatnagar Adeel Siddiqui Cable & Wireless Cable & Wireless 11700 Plaza America Drive, 11700 Plaza America Drive, 10th Floor 10th Floor Reston VA 20190 Reston VA 20190 USA USA Aditya.Bhatnagar@cwusa.com Adeel.Siddiqui@cwusa.com Riad Hartani Tricci So Caspian Networks Caspian Networks Address: 170 Baytech Drive, Address: 170 Baytech Drive, San Jose, CA, U.S.A., 95134 San Jose, CA, U.S.A., 95134 Phone: 408-382-5216 Phone: 408-382-5588 Email: riad@caspiannetworks.com Email: tso@caspiannetworks.com St-Denis Informational-Expires May 2001 18 Multi-service over MPLS November 2000 Full Copyright Statement "Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. St-Denis Informational-Expires May 2001 19