[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/