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]