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

Versions: 00 01

  PWE3 Working Group                                             Luca Martini
  Internet Draft                                              Nasser El-Aawar
  Expiration Date: December 2002                 Level 3 Communications, LLC.
 
                                                               Jeremy Brayley
  Rick Wilder                                                 Gerald de Grace
  Masergy Communications                                         John Shirron
                                                        Laurel Networks, Inc.
  Dimitri Stratton Vlachos
  Mazu Networks, Inc.                                         Andrew G. Malis
                                                        Vivace Networks, Inc.
  Tom Johnson
  Litchfield Communications, Inc.                         Jayakumar Jayakumar
                                                              Durai Chinnaiah
  Chris Liljenstolpe                                               Dan Tappan
  Cable & Wireless                                                 Eric Rosen
                                                          Cisco Systems, Inc.
  John Rutemiller
  Marconi Networks                                              Laura Dominik
                                                   Qwest Communications, Inc.
  Giles Heron
  PacketExchange Ltd.                                        Kireeti Kompella
                                                             Juniper Networks
  Neil Harrison
  British Telecom                                                   Tom Walsh
                                                          Lucent Technologies
 
                                                                    June 2002
 
 
     Encapsulation Methods for Transport of ATM Cells/Frame Over IP and
                               MPLS Networks
                    draft-martini-atm-encap-mpls-01.txt
 
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of section 10 of RFC 2026 [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.
 
 Martini, et al.         Expires December 2002                [Page 1]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
 Abstract
 
    A framework for providing various Layer 1 and Layer 2 services over
    a Packet Switched Network has been described in [3]. This draft
    provides encapsulation formats and guidelines for transporting a
    variety of ATM services over a PSN.
 
    This draft includes refinements to draft-brayley-pwe3-atm-service
    that was previously submitted to the PWE3 working group. It reuses
    the ATM cell and AAL5 encapsulation defined in the original martini
    encapsulation draft [7], but includes an applicability statement
    for each service along with ATM OAM handling and QoS guidelines.
 
 Table of Contents
 
 
    1 Conventions used in this document..............................3
    2 Introduction...................................................3
    3 Terminology....................................................4
    4 ATM Service Encapsulation......................................5
     4.1 ATM control Word............................................5
        4.1.1 Setting the sequence number............................6
        4.1.2 Processing the sequence number.........................7
    5 ATM Cell Relay Services........................................8
     5.1 VCC Cell Relay Service......................................8
        5.1.1 Applicability Statement................................8
        5.1.2 ATM OAM Cell Support...................................9
     5.2 VPC Cell Relay Service.....................................10
        5.2.1 Applicability Statement...............................10
        5.2.2 ATM OAM Cell Support..................................11
     5.3 Cell Relay encapsulation format............................12
     5.4 Review of header information...............................12
    6 AAL5 Payload VCC Service (AAL5-SDU mode)......................13
     6.1 Applicability Statement....................................13
     6.2 Encapsulation..............................................14
     6.3 ATM OAM Cell Support.......................................15
    7 ILMI support..................................................16
    8 QoS considerations............................................16
    9 Security Considerations.......................................17
    10 Intellectual Property Disclaimer.............................17
    11 References...................................................18
    12 Authors' Addresses...........................................18
    13 Appendix A: ATM transparent port service.....................21
     13.1 Defect Handling...........................................21
 
 
 Martini, et al.         Expires December 2002                [Page 2]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
        13.1.1 Defect Indication using ATM Physical Layer OAM messages
         ............................................................22
        13.1.2 Defect Indication using Loss of Cell Delineation (LCD)23
        13.1.3 Comparison............................................24
 
 
 
 1 Conventions used in this document
 
    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].
 
 2 Introduction
 
    Many service providers have multiple service networks and the
    Operational Support System capabilities needed to support these
    existing service offerings.  Packet Switched Networks (PSNs) have
    the potential to reduce the complexity of a service providerÆs
    infrastructure by allowing virtually any existing digital service
    to be supported over a single networking infrastructure.
 
    The benefit of this model to a service provider is threefold:
 
      1. Leveraging of the existing systems and services to provide
      increased capacity from a packet switched core.
 
      2. Preserving existing network operational processes and
      procedures used to maintain the legacy services.
 
      3. Using the common packet switched network infrastructure to
      support both the core capacity requirements of existing services
      and the requirements of new services supported natively over the
      packet switched network.
 
    This draft describes a method to carry ATM services over IP, L2TP
    and MPLS.  It lists ATM specific requirements and provides
    encapsulation formats and semantics for connecting ATM edge
    networks through a core packet network using IP, L2TP or MPLS.  The
    techniques described in this draft will allow ATM service providers
    to take advantage of new technologies in the core in order to
    provide ATM multi-services.
 
    Figure 1, below displays the ATM services reference model.  This
    model is adapted from [3].
 
 
 
 
 
 
 
 
 Martini, et al.         Expires December 2002                [Page 3]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
                        |<------- Pseudo Wire ------>|
                        |                            |
                        |    |<-- PSN Tunnel -->|    |
                        V    V                  V    V
             ATM Service+----+                  +----+ ATM Service
       +-----+    |     | PE1|==================| PE2|     |    +-----+
       |     |----------|............PW1.............|----------|     |
       | CE1 |    |     |    |                  |    |     |    | CE2 |
       |     |----------|............PW2.............|----------|     |
       +-----+    |     |    |==================|    |     |    +-----+
             ^    |     +----+                  +----+     |    ^
             |    |    Provider                Provider    |    |
             |    |     Edge 1                  Edge 2     |    |
             |                                                  |
             |<-------------- Emulated Service ---------------->|
 
       Customer                                                Customer
        Edge 1                                                  Edge 2
 
                     Figure 1: ATM Service Reference Model
 
 
 3 Terminology
 
    Packet Switched Network - A Packet Switched Network (PSN) is an IP
    or MPLS network.
 
    Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to
    Edge (PWE3) is a mechanism that emulates the essential attributes
    of a service (such as a T1 leased line or Frame Relay) over a PSN.
 
    Customer Edge - A Customer Edge (CE) is a device where one end of
    an emulated service originates and terminates.  The CE is not aware
    that it is using an emulated service rather than a "real" service.
 
    Provider Edge - A Provider Edge (PE) is a device that provides PWE3
    to a CE.
 
    Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs
    carried over a PSN.  The PE provides the adaptation between the CE
    and the PW.
 
    Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that
    contains all of the data and control information necessary to
    provide the desired service.
 
    PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can
    be nested so that they are transparent to core PSN devices.
 
    PSN Bound - The traffic direction where information from a CE is
    adapted to a PW, and PW-PDUs are sent into the PSN.
    CE Bound - The traffic direction where PW-PDUs are received on
 
 Martini, et al.         Expires December 2002                [Page 4]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    a PW from the PSN, re-converted back in the emulated service, and
    sent out to a CE.
 
    Ingress û The point where the ATM service is encapsulated into a
    Pseudo Wire PDU (ATM to PSN direction.)
 
    Egress - The point where the ATM service is decapsulated from a
    Pseudo Wire PDU (PSN to ATM direction.)
 
 
 4 ATM Service Encapsulation
 
    This section describes the general encapsulation format for ATM
    over PSN pseudo wires.
 
 
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               PSN Transport Header (As Required)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Pseudo Wire Header                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ATM Control Word                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ATM Service Payload                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
         Figure 2: General format for ATM encapsulation over PSNs
 
 
    The PSN Transport Header depends on the particular tunneling
    technology in use (L2TP or MPLS).  This header is used to transport
    the encapsulated ATM information through the packet switched core.
 
    The Pseudo Wire Header identifies a particular ATM service on a
    tunnel.  Non-ATM services may also be carried on the PSN tunnel.
 
    The ATM Control Word is inserted before the ATM service payload. It
    may contain a length and sequence number in addition to certain
    control bits needed to carry the service.
 
    The ATM Service Payload is specific to the service being offered
    via the Pseudo Wire.  It is defined in the following sections.
 
 
 4.1 ATM control Word
 
    The ATM control word is part of the ATM specific header.  It is not
    required for all services.  The control word is designed to satisfy
    three requirements.
 
 Martini, et al.         Expires December 2002                [Page 5]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
 
         - Ability to detect out of order delivery of PDUs.
         - Ability to detect padding added by certain link
           technologies.
         - Control bits for ATM services.
 
 
    In all cases the egress PE MUST be aware of whether the ingress PE
    will send a control word over a specific Pseudo Wire.
    This may be achieved using static configuration or using Pseudo
    Wire specific signaling.
 
    The control word is defined as follows:
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Flags        |  Length   |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                        Figure 3: ATM control word
 
    The first 10 bits provide space for carrying ATM service specific
    flags.  These are defined in the ATM service descriptions below.
    If a particular service does not require the use of these flags,
    these bits MUST be set to 0 upon transmission and ignored upon
    receipt.
 
    The next 6 bits provide a length field, which is used as follows:
 
    The Pseudo Wire may traverse a network link that requires a minimum
    frame size.  (Ethernet is a practical example with a minimum frame
    size of 64 octets.)  Such links will apply padding to the Pseudo
    Wire PDU to reach its minimum frame size.  A mechanism is required
    for the egress PE to detect and remove such padding.
 
    If the total length of the Pseudo Wire PDU - including the control
    word - is less than 64 octets, the length field MUST be set to the
    PDU length. Otherwise the length field MUST be set to zero.
 
    The next 16 bits provide a sequence number that can be used to
    guarantee ordered packet delivery. The processing of the sequence
    number field is OPTIONAL.
 
    The sequence number space is a 16 bit, unsigned circular space. The
    sequence number value 0 is used to indicate an unsequenced packet.
 
 
 4.1.1 Setting the sequence number
 
    The following procedures MUST be used by the ingress PE if
    sequencing is desired for a given ATM service:
 
 Martini, et al.         Expires December 2002                [Page 6]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
 
         - the initial PDU transmitted on the Pseudo Wire MUST use
           sequence number 1
         - the PE MUST increment the sequence number by one for each
           subsequent PDU
         - when the transmit sequence number reaches the maximum 16 bit
           value (65535) the sequence number MUST wrap to 1
 
    If the ingress PE does not support sequence number processing, then
    the sequence number field in the control word MUST be set to 0.
 
 
 4.1.2 Processing the sequence number
 
    If the egress PE supports receive sequence number processing, then
    the following procedures MUST be used:
 
      When an ATM service is initially created, the "expected sequence
      number" associated with it MUST be initialized to 1.
 
      When a PDU is received on the Pseudo Wire associated with the ATM
      service, the sequence number MUST be processed as follows:
 
         - if the sequence number on the packet is 0, then the PDU
           passes the sequence number check
 
         - otherwise if the PDU sequence number >= the expected
           sequence number and the PDU sequence number - the expected
           sequence number < 32768, then the PDU is in order.
 
         - otherwise if the PDU sequence number < the expected sequence
           number and the expected sequence number - the PDU sequence
           number >= 32768, then the PDU is in order.
 
         - otherwise the PDU is out of order.
 
      If a PDU passes the sequence number check, or is in order then,
      it can be delivered immediately. If the PDU is in order, then the
      expected sequence number MUST be set using the algorithm:
 
      expected_sequence_number := PDU_sequence_number + 1 mod 2**16
      if (expected_sequence_number = 0)
                 then expected_sequence_number := 1;
 
      Pseudo Wire PDUs that are received out of order MAY be dropped or
      reordered at the discretion of the egress PE.
 
    If the egress PE does not support receive sequence number
    processing, then the sequence number field MAY be ignored.
 
 
 
 
 Martini, et al.         Expires December 2002                [Page 7]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
 5 ATM Cell Relay Services
 
    This section defines the VCC and VPC cell relay services over a PSN
    and their applicability.
 
 
 5.1 VCC Cell Relay Service
 
    A VCC cell relay service may be offered by mapping an ATM Virtual
    Channel Connection to a single Pseudo Wire.  The Pseudo Wire is
    identified by a unique value in the PW Header.
 
    The ingress PE may map one or more VCCs to a single Pseudo Wire.
 
    The VCC cell relay service assumes that a PE has the ability to
    change the VPI/VCI.  The egress PE may make its forwarding decision
    based on a combination of the incoming PW header and VPI/VCI within
    the PW PDU.
 
 
 5.1.1 Applicability Statement
 
    The VCC cell relay encapsulation described in this document allows
    a service provider to offer a PVC or SVC based VCC cell relay
    service across an IP or MPLS PSN.
 
    The encapsulation allows multiple VCCs to be carried within a
    single PSN tunnel.  This does not preclude the possibility that a
    service provider may wish to provision a single VCC to a PSN tunnel
    in order to satisfy QoS or restoration requirements.
 
    The encapsulation also supports the binding of multiple VCCs to a
    single Pseudo Wire.  This capability is useful in order to make
    more efficient use of the PW demultiplexing header space as well as
    to ease provisioning of the VCC services.
 
    The VCC cell relay service has the following attributes:
 
    1. Supports all ATM Adaptation Layers.
 
    2. Non-terminating OAM/Admin cells are transported among the user
       cells in the same order as they are received.  This requirement
       enables the use of various performance management and security
       applications.
 
    3. In order to gain transport efficiency on the PSN, multiple cells
       may be encapsulated in a single PW PDU.  This process is called
       ôcell concatenationö.  How many cells to insert or how long to
       wait for cell arrival before sending a PW PDU is an
       implementation decision.  Like any SAR scheme, cell
       concatenation introduces latency to a cell relay service.
 
 
 Martini, et al.         Expires December 2002                [Page 8]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    4. The CLP bit from each cell may be mapped to a corresponding
       marking on the PW PDU.  This allows the drop precedence to be
       preserved across the PSN.
 
    The VCC cell relay service encapsulation has the following
    drawbacks:
 
    1. There is no currently defined method to translate the forward
       congestion indication (EFCI) to a corresponding function in the
       PSN.  Nor is there a way to translate PSN congestion to the EFCI
       upon transmission by the egress PE.
 
    2. The ATM cell header checksum can correct a single bit error in
       the cell header.  Analogous functionality does not exist in most
       PSNs.  A single bit error in a PW PDU will most likely cause the
       packet to be dropped due to a L2 FCS failure.
 
    3. There is no currently defined method to support EPD/PPD on the
       PSN.
 
    4. There are currently no OAM mechanisms defined for the PSN like
       those defined for ATM.  Therefore the methods for the
       detection/consequent-actions of failures in the PSN are not
       specified.  This also means that QoS/availability metrics cannot
       be specified for the PSN.
 
 
 5.1.2 ATM OAM Cell Support
 
    When configured for a VCC cell relay service, both PEÆs SHOULD act
    as a VC switch in accordance with the procedures defined in [4].
 
    The PEs SHOULD be able to pass the following OAM cells
    transparently:
         - F5 AIS (segment and end-to-end)
         - F5 RDI (segment and end-to-end)
         - F5 loopback (segment and end-to-end)
         - Resource Management
         - Performance Management
         - Continuity Check (segment and end-to-end)
         - Security
 
    The ingress PE SHOULD be able to generate an F5 AIS upon reception
    of a corresponding F4 AIS from the CE or due to a lower layer
    defect (such as LOS) on the ingress PE port.
 
    The egress PE SHOULD be able to generate an F5 AIS for the VCC due
    to a PSN failure.  A method to reliably detect a PSN tunnel failure
    is required but not specified in this draft.
 
    If the ingress PE cannot support the generation of OAM cells, it
    MAY notify the egress PE using a Pseudo Wire specific maintenance
 
 Martini, et al.         Expires December 2002                [Page 9]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    mechanism to be defined.  For example, the ingress PE MAY withdraw
    the Pseudo Wire (VC label) associated with the service.  Upon
    receiving such a notification, the egress PE SHOULD generate the
    appropriate F5 AIS.
 
 
 5.2 VPC Cell Relay Service
 
    A Virtual Path Connection cell relay service may be offered by
    mapping an ATM Virtual Path Connection to a single Pseudo Wire.
    Like the VCC cell relay service, the Pseudo Wire is identified by a
    unique value in the PW Header.
 
    The ingress PE may map one or more VPCs to a single Pseudo Wire.
 
    The VPC cell relay service assumes that a PE has the ability to
    change the VPI.  As befitting a VP level service, the VCI must
    remain constant.  The egress PE may make its forwarding decision
    based on a combination of the incoming PW header and VPI within the
    PW PDU.
 
 
 5.2.1 Applicability Statement
 
    The VPC cell relay encapsulation described in this document allows
    a service provider to offer a PVC or SVC based VPC cell relay
    service across an IP or MPLS PSN.
 
    The encapsulation allows multiple VPCs to be carried within a
    single PSN tunnel.  This does not preclude the possibility that a
    service provider may wish to provision a single VPC to a PSN tunnel
    in order to satisfy QoS or restoration requirements.
 
    The encapsulation also supports the binding of multiple VPCs to a
    single Pseudo Wire.  This capability is useful to ease provisioning
    of several VPCs.
 
    The VPC cell relay service shares many of the same attributes of
    the VCC cell relay service as defined above:
 
    1. Non-terminating OAM/Admin cells are transported among the user
       cells in the same order as they are received.
 
    2. The encapsulation also allows cell concatenation.  If enough
       cells are inserted into a single PW PDU the resulting byte
       stream can become more efficient than a native ATM service.
 
    3. The CLP bit from each cell may be mapped to a corresponding
       marking on the PW PDU.  This allows the drop precedence to be
       preserved across the PSN.
 
 
 
 Martini, et al.         Expires December 2002               [Page 10]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    The VPC cell relay service encapsulation has the following
    drawbacks:
 
    1. There is no currently defined method to translate the forward
       congestion indication (EFCI) to a corresponding function in the
       PSN.  Nor is there a way to translate PSN congestion to the EFCI
       upon transmission by the egress PE.
 
    2. The ATM cell header checksum can correct a single bit error in
       the cell header.  Analogous functionality does not exist in most
       PSNs.  A single bit error in a PW PDU will most likely cause the
       packet to be dropped due to a L2 FCS failure.
 
    3. There are currently no OAM mechanisms defined for the PSN like
       those defined for ATM.
 
 
 5.2.2 ATM OAM Cell Support
 
    When configured for a VPC cell relay service, both PEs SHOULD act
    as a VP cross-connect in accordance with the OAM procedures defined
    in [4].
 
    The PEs SHOULD be able to pass the following ATM OAM cells
    transparently:
         - F4 AIS (segment and end-to-end)
         - F4 RDI (segment and end-to-end)
         - F4 loopback (segment and end-to-end)
         - F5 AIS (segment and end-to-end)
         - F5 RDI (segment and end-to-end)
         - F5 loopback (segment and end-to-end)
         - Resource Management
         - Performance Management
         - Continuity Check (segment and end-to-end)
         - Security
 
 
    The ingress PE SHOULD be able to generate an F4 AIS due to a lower
    layer defect (such as LOS) on the ingress PE port.
 
    The egress PE SHOULD be able to generate an F4 AIS for the VPC due
    to a PSN failure.
 
    If the ingress PE cannot support the generation of OAM cells, it
    MAY notify the egress PE using a Pseudo Wire specific maintenance
    mechanism to be defined.  For example, the ingress PE MAY withdraw
    the Pseudo Wire (VC label) associated with the service.  Upon
    receiving such a notification, the egress PE SHOULD generate the
    appropriate F4 AIS.
 
 
 
 
 Martini, et al.         Expires December 2002               [Page 11]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
 5.3 Cell Relay encapsulation format
 
    The VCC and VPC cell relay services use a common encapsulation
    format.  The ATM control word as defined in section 4.1.  Its use
    is OPTIONAL and necessary only if sequencing is desired.  If the
    ATM control word is used, then the Flag and Length fields should be
    set to 0 upon transmission and ignored upon receipt.  If sequencing
    is not used, the control word must not be present.
 
 
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    ATM control word (optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          VPI          |              VCI              | PTI |C|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          "                                    |
      |                  ATM Payload (48 octets)                      |
      |                          "                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          VPI          |              VCI              | PTI |C|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          "                                    |
      |                  ATM Payload (48 octets)                      |
      |                          "                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                 Figure 4: VCC and VPC cell relay encapsulation
 
 
 
 5.4 Review of header information
 
    The review of the ATM header at PE devices is OPTIONAL.  While
    information carried in the cell encapsulation is carried
    transparently through the PSN, and does not require a SAR function,
    inspection of the header information provides a mechanism to map
    characteristics of the transported information to the PSN.  Each
    cell is inspected at the PE device and service requirements are
    mapped accordingly in the packet based network.
 
    It is through this examination that control mechanisms such as
    congestion management can be translated for transport in the PSN.
    This capability could also be used to support the mapping of ATM
    QoS to CoS.
 
    Direct examination of the header provides a view of the CLP field
    and the payload type indicator (PTI) field on a per cell basis.
    The PTI field provides the ATM User-to-User indication (used by
 
 
 Martini, et al.         Expires December 2002               [Page 12]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    some AALs), upstream congestion, and discrimination between user
    and admin cells.  Payload types carrying user information can also
    indicate (i) whether congestion was experienced (by EFCI) or (ii)
    whether the cell contains an indication of the last cell of an AAL5
    PDU.
 
    A specific implementation is the mapping of the CLP bit into a MPLS
    based core network.  In order to emulate drop precedence on a MPLS
    tunnel, the CLP bit is associated with a pair of configurable MPLS
    EXP values. Cells with CLP = 0 are encapsulated into a MPLS packet
    with EXP = 000.  Cells with CLP = 1 are encapsulated with EXP =
    001. This information is carried in all levels of labels as
    necessary.
 
 
 6 AAL5 Payload VCC Service (AAL5-SDU mode)
 
    The AAL5 payload VCC service defines a mapping between the payload
    of an AAL5 VCC and a single Pseudo Wire.  The AAL5 payload VCC
    service requires ATM segmentation and reassembly support on the PE.
 
    The AAL5 payload VCC service is OPTIONAL.
 
    Even the smallest TCP packet requires two ATM cells when sent over
    AAL5 on a native ATM device.  It is desirable to avoid this padding
    on the Pseudo Wire.  Therefore, once the ingress PE reassembles the
    AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer then
    inserts the resulting payload into a Pseudo Wire PDU.
 
    The egress PE MUST regenerate the PAD and trailer before
    transmitting the AAL5 frame on the egress ATM port.
 
    This service does allow the transport of OAM and RM cells, but does
    not attempt to maintain the relative order of these cells with
    respect to the cells that comprise the AAL5 CPCS-PDU.  OAM cells
    that arrive during the reassembly of a single AAL5 CPCS-PDU are
    sent immediately on the Pseudo Wire, followed by the AAL5 payload.
    Therefore, the AAL5 payload VCC service will not be suitable for
    ATM applications that require strict ordering of OAM cells (such as
    performance monitoring and security applications).
 
 
 6.1 Applicability Statement
 
    It is possible to carry any ATM service using the VCC and VPC cell
    relay encapsulations defined in the previous section.  After all,
    ATM is inherently a cell-based technology.  However, a vast
    majority of the data carried on ATM networks is frame based and
    therefore uses AAL5.   For example, most Frame Relay services are
    provided on an ATM backbone using AAL5 and of course AAL5 is used
    to carry IP PDUs between ATM attached routers.
 
 
 Martini, et al.         Expires December 2002               [Page 13]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    The AAL5-SDU service is designed with this reality in mind.  The
    encapsulation defined below is more efficient for small AAL5 SDUs
    than the VCC cell relay service.  In turn it presents a more
    efficient alternative to the cell relay service when carrying RFC
    2684 encapsulated IP PDUs across a PSN.
 
    The AAL5-SDU encapsulation requires Segmentation and Reassembly on
    the PE-CE ATM interface.  This SAR function is provided by common
    off-the-shelf hardware components.  Once reassembled, the AAL5-SDU
    is carried via a Pseudo Wire to the egress PE.  Herein lies another
    advantage of the AAL5-SDU encapsulation.  Using the AAL5-SDU mode
    the egress PE does not have to perform reassembly itself on the PSN
    facing interface when converting to a frame based medium.  For
    example, the AAL5-SDU mode allows easier extraction of an IP PDU
    for processing, or conversion to a different frame technology such
    as Frame Relay or Ethernet.  When using the cell relay service to
    provide this same functionality, the egress PE must reassemble
    cells arriving over a PSN tunnel.
 
 
 6.2 Encapsulation
 
    The AAL5 payload service encapsulation is shown below.
 
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              "                                |
      |                     ATM cell or AAL5 CPCS-SDU                 |
      |                              "                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 5: AAL5 payload service encapsulation
 
         The AAL5 payload service encapsulation requires the ATM
         control word.  The Flag bits are described below.
 
         * Res (Reserved)
 
         These bits are reserved and MUST be set to 0 upon transmission
         and ignored upon reception.
 
         * T (Transport type) bit
 
         Bit (T) of the control word indicates whether the packet
         contains an ATM admin cell or an AAL5 payload. If T = 1, the
         packet contains an ATM admin cell, encapsulated according to
         the VCC cell relay encapsulation of section Error! Reference
         source not found..  If not set, the PDU contains an AAL5
         payload.  The ability to transport an ATM cell in the AAL5 SDU
 
 Martini, et al.         Expires December 2002               [Page 14]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
         mode is intended to provide a means of enabling administrative
         functionality over the AAL5 VCC (though it does not endeavor
         to preserve user-cell and admin-cell arrival/transport
         ordering).
 
 
         * E (EFCI) Bit
 
         The ingress PE device SHOULD set this bit to 1 if the EFCI bit
         of the final cell of the incoming AAL5 payload is set to 1, or
         if the EFCI bit of the single ATM cell to be transported in
         the packet is set to 1.  Otherwise this bit SHOULD be set to
         0.  The egress PE device SHOULD set the EFCI bit of all the
         outgoing cells that transport the AAL5 payload to the value
         contained in this field.
 
         * C (CLP) Bit
 
         The ingress PE device SHOULD set this bit to 1 if the CLP bit
         of any of the incoming ATM cells of the AAL5 payload are set
         to 1, or if the CLP bit of the single ATM cell that is to be
         transported in the packet is set to 1.  Otherwise this bit
         SHOULD be set to 0. The egress PE device SHOULD set the CLP
         bit of all outgoing cells that transport the AAL5 CPCS-PDU to
         the value contained in this field.
 
 
         * U (Command/Response) Bit
 
         When FRF.8.1 Frame Relay / ATM PVC Service Interworking (see
         [5]) traffic is being transported, the CPCS-UU Least
         Significant Bit (LSB) of the AAL5 CPCS-PDU may contain the
         Frame Relay C/R bit.
         The ingress PE device SHOULD copy this bit to the U bit of the
         control word. The egress PE device SHOULD copy the U bit to
         the CPCS-UU Least Significant Bit (LSB) of the AAL5 payload.
 
         The Length and Sequence Number fields are described in section
         4.1.
 
         In case of a reassembly timeout, the encapsulating PE should
         discard all component cells of the AAL5 frame.
 
 
 6.3 ATM OAM Cell Support
 
    Similar to the VCC cell relay service, both PEs SHOULD act as a VC
    switch in accordance with the OAM procedures defined in [4].
 
    The PEs SHOULD be able to pass the following OAM cells
    transparently:
         - F5 AIS (segment and end-to-end)
 
 Martini, et al.         Expires December 2002               [Page 15]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
         - F5 RDI (segment and end-to-end)
         - F5 loopback (segment and end-to-end)
         - Resource Management
         - Continuity Check (segment and end-to-end)
 
    Because this service does not guarantee the original OAM cell
    position within the AAL5 composite cells, the following cell types
    are discarded by the ingress PE:
         - Performance Management
         - Security
 
    The ingress PE SHOULD be able to generate an F5 AIS upon reception
    of a corresponding F4 AIS from the CE or due to a lower layer
    defect (such as LOS) on the ingress PE port.
 
    The egress PE SHOULD be able to generate an F5 AIS for the VCC due
    to a PSN failure.  A method to reliably detect a PSN tunnel failure
    is required but not specified in this draft.
 
    If the ingress PE cannot support the generation of OAM cells, it
    MAY notify the egress PE using a Pseudo Wire specific maintenance
    mechanism to be defined.  For example, the ingress PE MAY withdraw
    the Pseudo Wire (VC label) associated with the service.  Upon
    receiving such a notification, the egress PE SHOULD generate the
    appropriate F5 AIS.
 
 
 7 ILMI support
 
    Integrated Local Management Interface (ILMI) typically is used in
    ATM networks for neighbor resource availability detection, address
    registration, auto-configuration, and loss of connectivity
    detection.  ILMI messages are sent as SNMP PDUs within ATM AAL5
    cells.
 
    A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE
    receives an ILMI message indicating that the ATM service (VCC or
    VPC) is down, it MAY use a Pseudo Wire specific mechanism to notify
    the egress PE of the ATM service status.  For example, a PE using
    an MPLS based Pseudo Wire may withdraw its advertised VC label.
 
    When receiving such a notification, the egress PE MAY use ILMI to
    signal the ATM service status to its attached CE.
 
 
 8 QoS considerations
 
    The ingress PE should have the ability to maintain separation of
    ATM traffic classes (i.e. CBR, rt-VBR, nrt-VBR, ABR, and UBR) for
    each of the services transported across the PSN.  The mechanism
    used to maintain these traffic classes depends upon the PSN in use.
 
 
 Martini, et al.         Expires December 2002               [Page 16]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    For example, does the PSN support resource assignments per PSN
    tunnel?  Can it support per PSN tunnel queuing?
 
    The actual mechanisms to support the ATM traffic classes should be
    left up to the operator.  This section offers some suggestions.
 
    QoS assignment on the PSN requires close inspection of incoming
    cell headers.  This includes mapping the VPI/VCI to a specific PSN
    traffic class and using the CLP bit to determine the PSN drop
    precedence.  For example, when processing incoming cells for a CBR
    VCC service, the ingress PE may mark the outgoing Pseudo Wire PDUs
    with a particular DSCP or MPLS EXP.  (Marking depends upon the PSN
    in use.)  Downstream PSN devices should use this marking to map
    these PW PDU's to queuing and scheduling resources that emulate an
    ATM CBR service (i.e. low latency, guaranteed bandwidth).
 
    If the PSN is MPLS based, the ingress PE may associate ATM services
    with E-LSPs or L-LSPs as defined in [8].
 
    The PSN should also have the ability to maintain the ATM cell loss
    priority (CLP) of incoming cells.  For example, in case of an MPLS
    based PSN, the ingress PE may mark both the PSN transport and
    Pseudo Wire labels with EXP = 010 or EXP = 011 depending upon the
    incoming cell's CLP value.  (If the PW PDU contains multiple ATM
    cells the ingress PE should not mark the PW PDU to convey a single
    drop precedence.)  For AAL5 services, the ingress PE should mark
    the PW PDU using the same algorithm that determines the C (CLP) bit
    (i.e if any cell has CLP = 1 then the C bit should be set to 1.)
 
    The following is an example of mapping ATM service classes and CLP
    to a Diff-Serv capable PSN.
 
    ATM traffic class    CLP          PSN marking
    ---------------------------------------------------
    CBR                   0      DSCP=000110 or EXP=110
    CBR                   1      DSCP=000111 or EXP=111
    rt-VBR                0      DSCP=000100 or EXP=100
    rt-VBR                1      DSCP=000101 or EXP=101
    nrt-VBR               0      DSCP=000010 or EXP=010
    nrt-VBR               1      DSCP=000011 or EXP=011
    UBR                   0      DSCP=000000 or EXP=000
    UBR                   1      DSCP=000001 or EXP=001
 
 
 9 Security Considerations
 
    This draft does not introduce any new security considerations to IP
    or MPLS.
 
 
 10 Intellectual Property Disclaimer
 
 
 Martini, et al.         Expires December 2002               [Page 17]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    This document is being submitted for use in IETF standards
    discussions.
 
 11 References
 
    [1]  Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.
 
    [2]  Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels", BCP 14, RFC 2119, March 1997
 
    [3]  "Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)",
         draft-ietf-pwe3-requirements-01.txt, Work in Progress
 
    [4]  ITU-T Recommendation I.610, "B-ISDN operation
         and maintenance principles and functions", February 1999
 
    [5]  "Frame Relay / ATM PVC Service Interworking Implementation
         Agreement (FRF.8.1)", Frame Relay Forum 2000.
 
    [6]  "Frame Based ATM over SONET/SDH Transport (FAST)," ATM Forum
         2000.
 
    [7]  "Encapsulation Methods for Transport of Layer 2 Frames Over
         MPLS", draft-martini-l2circuit-encap-mpls-04.txt, Work in
         Progress
 
    [8]  "MPLS Support of Differentiated Services", draft-ietf-mpls-
         diff-ext-09.txt, Work in Progress
 
    [9]  ITU-T Recommendation I.432.2, "B-ISDN User-Network Interface
         Physical Layer specification: 155 520 kbit/s and 622 080
         kbit/s operation", February 1999
 
 
 12 Authors' Addresses
 
    Luca Martini
    Level 3 Communications, LLC.
    1025 Eldorado Blvd.
    Broomfield, CO, 80021
    Email: luca@level3.net
 
    Nasser El-Aawar
    Level 3 Communications, LLC.
    1025 Eldorado Blvd.
    Broomfield, CO, 80021
    Email: nna@level3.net
 
    Jeremy Brayley
    Laurel Networks, Inc.
    1300 Omega Drive
 
 Martini, et al.         Expires December 2002               [Page 18]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    Pittsburgh, PA 15205
    Email: jbrayley@laurelnetworks.com
 
    Gerald de Grace
    Laurel Networks, Inc.
    1300 Omega Drive
    Pittsburgh, PA 15205
    Email: gdegrace@laurelnetworks.com
 
    John Shirron
    Laurel Networks, Inc.
    1300 Omega Drive
    Pittsburgh, PA 15205
    Email: jshirron@laurelnetworks.com
 
    Andrew G. Malis
    Vivace Networks, Inc.
    2730 Orchard Parkway
    San Jose, CA 95134
    Email: Andy.Malis@vivacenetworks.com
 
    Jayakumar Jayakumar
    Cisco Systems, Inc.
    225, E. Tasman, MS-SJ3/3,
    San Jose, CA, 95134
    Email: jjayakum@cisco.com
 
    Durai Chinnaiah
    Cisco Systems, Inc.
    225, E. Tasman, MS-SJ3/3,
    San Jose, CA, 95134
    Email: dchinnai@cisco.com
 
    Dan Tappan
    Cisco Systems, Inc.
    50 Apollo Drive
    Chelmsford, MA, 01824
    Email: tappan@cisco.com
 
    Eric Rosen
    Cisco Systems, Inc.
    250 Apollo Drive
    Chelmsford, MA, 01824
    Email: erosen@cisco.com
 
    Rick Wilder
    Masergy Communications
    2901 Telestar Ct.
    Falls Church, VA 22042
    Email: rwilder@masergy.com
 
    Dimitri Stratton Vlachos
 
 Martini, et al.         Expires December 2002               [Page 19]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    Mazu Networks, Inc.
    125 Cambridgepark Drive
    Cambridge, MA 02140
    Email: d@mazunetworks.com
 
    Thomas K. Johnson
    Litchfield Communications, Inc.
    76 Westbury Park Rd.
    Watertown, CT 06795
    Email: tom_johnson@litchfieldcomm.com
 
    Chris Liljenstolpe
    Cable & Wireless
    11700 Plaza America Drive
    Reston, VA 20190
    Email: chris@cw.net
 
    John Rutemiller
    Marconi Networks
    1000 Marconi Drive
    Warrendale, PA 15086
    Email: John.Rutemiller@marconi.com
 
    Giles Heron
    PacketExchange Ltd.
    The Truman Brewery
    91 Brick Lane
    LONDON E1 6QL
    United Kingdom
    Tel.: +44 7880 506185
    Email: giles@packetexchange.net
 
    Laura Dominik
    Qwest Communications, Inc.
    600 Stinson Blvd.
    Minneapolis, MN, 55413
    Email: ldomini@qwest.com
 
    Kireeti Kompella
    Juniper Networks
    1194 N. Mathilda Ave
    Sunnyvale, CA 94089
    Email: kireeti@juniper.net
 
    Tom Walsh
    Lucent Technologies
    1 Robbins Road
    Westford, MA 01886 USA
    Email: tdwalsh@lucent.com
 
    Neil Harrison
    British Telecom
 
 Martini, et al.         Expires December 2002               [Page 20]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    Email: neil.2.Harrison@bt.com
 
 
 
 
 13 Appendix A: ATM transparent port service
 
    The main application of the transparent port service is to migrate
    ATM services to a PSN without having to provision the ATM CE
    devices.  The ATM CEs will view the ATM transparent port service as
    if they were directly connected via a TDM leased line.  This
    ôserviceö is most likely to be used as an internal function in a
    ATM service providerÆs network as a way to connect existing ATM
    switches via a higher speed PSN.
 
    The transparent port service is a natural benefit of the cell relay
    encapsulation specified above.  Previous versions of this document
    included the transparent port service as just another cell relay
    service.  However, although this service is very useful for the
    reasons above, there are concerns about defect handling.  Therefore
    weÆve moved the transparent port service to this appendix as a
    application of the cell relay encapsulations.
 
    The ATM transparent port service emulates connectivity between two
    remote ATM ports. This service is useful when one desires to
    connect two CEs without interfering at the VPC or VCC layer.  The
    ingress PE MUST discard any idle/unassigned cells received from the
    ingress ATM port, and map all other received cells to a single
    Pseudo Wire.
 
    The egress PE SHOULD not change the VPI, VCI, PTI, or CLP bits when
    it sends these cells on the egress ATM port.  Therefore the
    transparent port service appears to emulate an ATM transmission
    convergence layer connection between two ports.  However, since the
    ingress PE discards idle/unassigned cells, this service benefits
    from statistical multiplexing.
 
    This service MUST use the VCC cell relay encapsulation defined
    in section 5.3.
 
 
 13.1 Defect Handling
 
    Transparent port service provides a capability similar to a cell-
    based transmission repeater service. The ATM cell stream is
    transparently carried from the source to the destination on a per-
    port basis. The interworking function (PE device) acts as a
    repeater for this service.
 
    For purposes of defect handling, transparent port service is
    modeled as an F3 layer capability. The interworking function acts
    as a cell repeater between the SONET/SDH link and the MPLS Pseudo-
 
 Martini, et al.         Expires December 2002               [Page 21]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    Wire. Procedures are based loosely on I.432.2 [9], section 7.2.2.4.
    Only maintenance signals are supported. Performance monitoring is
    not supported. It is assumed that the SONET/SDH link and the PSN
    Pseudo-wire provide this function.
 
    ATM switches may implement F3 level cell-based services to achieve
    end-to-end performance monitoring. The procedures for applying this
    capability to PSN cell-based transmission are outside the scope of
    this document.
 
    This service is completely transparent to the ATM F4 and F5 fault
    management layer. The PEÆs MUST not terminate ATM F4/F5 OAM or
    admin cells.
 
    Transparent port service must provide indications to the egress ATM
    device regarding the presence of an upstream failure. There are two
    types of upstream failures.
 
    1) Failure of the Pseudo wire.
 
    2) Failure of the transmission path from the ingress ATM device.
 
    The mechanism used by the Pseudo wire to indicate a failure is
    outside the scope of this document. Possible mechanisms are to
    withdraw the PW, indicate a change of status using signaling, or
    some form of OAM mechanism.
 
    Upon indication of an upstream failure, an indication MUST be sent
    to the egress ATM device. A fault is indicated either by sending an
    ATM physical layer OAM message or disrupting the cell stream
    forcing a downstream Loss of Cell Delineation (LCD).
 
    Both procedures MUST be supported and MUST be configurable per
    link.
 
 
 13.1.1 Defect Indication using ATM Physical Layer OAM messages
 
    Physical Layer OAM cells are used by this document to provide an
    additional F3 transmission path layer above the F3 transmission
    path layer provided by SONET/SDH, or PDH interfaces.
 
    The use of this capability requires support from the ATM devices at
    both ends of the PSN transparent port service.
 
    The Physical Layer OAM cell is adapted from I.432.2. Only the IAS
    and RDI capabilities are supported.
 
    The format of the ATM cell is shown in Figure 6:
 
 
 
 
 Martini, et al.         Expires December 2002               [Page 22]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          VPI=0        |           VCI=0               |0|1|1|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      HEC      |      6 A      |      AIS      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      RDI      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |      6 A      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      6 A      |      6 A      |      6 A      |0 0 0 0 0 0|CEC|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     C E C     |
      +-+-+-+-+-+-+-+-+
 
         Figure 6: Cell format for Transparent Port Service Maintenance
 
 
    Upon detection of a failure in the PSN Pseudo-wire, the
    interworking function (egress PE device) must send a Transmission
    Path Alarm Indication Signal (TP-AIS) to the egress ATM device by
    placing the value 0x01 in the second octet of the ATM cell payload.
    ATM devices implementing this capability must send a Transmission
    Path Remote Defect Indication (TP-RDI) by placing the value 0x01 in
    the 30th octet of the ATM cell payload.
 
 
 13.1.2 Defect Indication using Loss of Cell Delineation (LCD)
 
    Defect indication using Loss of Cell Delineation (LCD) is
    accomplished by disrupting the cell stream without affecting the
    lower transmission layers.
 
 
 
 
 
 Martini, et al.         Expires December 2002               [Page 23]


 Internet Draft  draft-martini-atm-encap-mpls-01.txt          June 2002
 
    The LCD condition will occur if the state of the cell scrambling is
    changed. With cell scrambling disabled, the egress ATM device will
    not be able to locate a valid HEC value.
 
    Disabling the cell scrambler has the potential of causing faults in
    the lower layer, or false cell delineation. This can happen if the
    cell payload contains certain patterns.
 
    This is not a problem during the failure because upstream ATM cells
    will not be arriving. The only cells sent to the egress ATM device
    will be Idle/Unassigned cells.
 
    The potential vulnerability is during the time when the upstream
    service is restored and the cell scrambler is re-enabled.
 
    To prevent this vulnerability, the transparent port service MUST
    disconnect the Pseudo Wire from the egress path prior to disabling
    cell scrambling. After the upstream failure is cleared, the
    transparent port service MUST re-enable the cell scrambler prior to
    re-connecting the Pseudo Wire to the egress path.
 
 
 13.1.3 Comparison
 
    The advantage of using physical layer OAM messages is it provides
    proper defect notification and alarm management.
 
    The disadvantage of using physical layer OAM messages is that the
    ATM Physical Layer OAM cells is not currently supported for non-
    cell based interface types, and therefore is not supported by
    existing ATM equipment.
 
    The advantage of using Loss of Cell Delineation is it will work
    with existing ATM devices.
 
    The disadvantage of using Loss of Cell Delineation is that is will
    cause an improper alarm condition at the egress CE device. However,
    the alarm condition will not propagate beyond the egress CE device.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Martini, et al.         Expires December 2002               [Page 24]
 

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