PWE3 Working Group John Fischer
Internet Draft Matthew Bocci
Expiration Date: February 2002 Alcatel
A. Siddiqui Mina Azad
Cable & Wireless Ghassem Koleyni
Nortel Networks
September 2001
PWE3: ATM service description
draft-fischer-pwe3-atm-service-00.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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)
have been described in [6]. This draft 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. This basic application of ATM interworking will
allow ATM service providers to take advantage of new technologies
in the core in order to provide ATM multi-services.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
Table of Contents
1 Conventions used in this document..............................3
2 Introduction...................................................3
3 Terminology....................................................4
4 General Requirements...........................................5
5 ATM Service Encapsulation......................................5
5.1 Length and Sequence Number ..................................6
5.1.1 Setting the sequence number ............................7
5.1.2 Processing the sequence number .........................7
6 ATM VCC Services...............................................8
6.1 ATM VCC Cell Transport Service ..............................8
6.1.1 ATM OAM Cell Support ..................................10
6.2 ATM VCC Frame Transport Service ............................11
6.2.1 Transparent AAL5 PDU Frame Service ....................11
6.2.1.1 OAM Cell Support ..................................13
6.2.1.2 Fragmentation .....................................13
6.2.1.2.1 Procedures in the ATM-to-MPLS Direction ......13
6.2.1.2.2 Procedures in the MPLS-to-ATM Direction ......14
6.2.2 AAL5 SDU Frame Service ................................14
6.2.3 OAM Cell Support ......................................15
7 ATM VPC Services..............................................16
7.1 ATM VPC Cell Transport Services ............................16
7.1.1 OAM Cell Support ......................................18
8 ATM Port Services.............................................19
8.1 OAM Cell Support ...........................................20
9 ILMI support..................................................20
10 QoS considerations...........................................21
11 Pseudo-Wire specific requirements............................21
11.1 MPLS requirements .........................................21
11.1.1 MPLS Transport Label .................................22
11.1.2 MPLS Pseudo Wire Label ...............................22
11.2 L2TP requirements .........................................23
11.3 IP requirements ...........................................23
12 Security Considerations......................................23
13 Intellectual Property Disclaimer.............................23
14 References...................................................23
15 Acknowledgments..............................................24
16 Authors' Addresses...........................................24
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 [6].
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
|<------- 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 a
network using IP, MPLS or L2TP as the unit of switching.
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 network
devices.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 General Requirements
For transport of an ATM service across a PSN, the PSN SHOULD be
able to:
1. Carry all AAL types transparently.
2. Carry multiple ATM connections (VPCs and/or VCCs).
3. Support ATM OAM applications.
4. Transport Cell Loss Priority (CLP) and Payload Type Indicator
(PTI) information from the ATM cell header.
5. Provide a mechanism to detect mis-ordering of ATM cells over
the PSN.
6. Support traffic contracts and the QoS commitments made to the
ATM connections (through the use of existing IETF defined
Diff-Serv techniques).
5 ATM Service Encapsulation
This section describes the general encapsulation format for ATM
over PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics
pertaining to each packet technology are covered in later
sections.
Figure 2 provides a general format for encapsulation of ATM cells
(or frames) into packets.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequence Number ] | ATM Specific |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Service Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: General format for ATM encapsulation over PSNs
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
The PSN Transport Header depends on the packet technology: IP,
L2TP or MPLS. This header is used to transport the encapsulated
ATM information through the packet switched core. This header is
always present if the Pseudo Wire is MPLS.
The Pseudo Wire Header depends on the packet technology: IP, L2TP
or MPLS. It identifies a particular ATM service within the PSN
tunnel.
The Length and Sequence Number is inserted after the Pseudo Wire
Header. These fields are optional.
The ATM Specific Header is inserted before the ATM service
payload. The ATM Specific Header certain control bits needed to
carry the service. These are defined in the ATM service
descriptions below. The length of ATM specific header may not
always be one octet. It depends on the service type.
The ATM payload octet group is the payload of the service that is
being encapsulated.
5.1 Length and Sequence Number
The length and sequence is not required for all services. The
control word is designed to satisfy these requirements.
- Sequentiality may need to be preserved.
- Small packets may need to be padded in order to be
transmitted on a medium where the minimum transport unit is
larger than the actual packet size.
The one-octet Length indicates length of the packet payload that
includes Sequence number length, the ATM specific header length
and the payload length (i.e., Pseudo Wire PDU). The Length field
is set to 0 by the ingress PE if not used and is ignored by the
egress PE.
If the Pseudo Wire traverses a network link that requires a
minimum frame size such as Ethernet as a practical example, with a
minimum frame size of 64 octets, then such links will apply
padding to the Pseudo Wire PDU to reach its minimum frame size. In
this case the length field MUST be set to the PDU length. A
mechanism is required for the egress PE to detect and remove such
padding.
The Sequence Number is a 2-octet field that may be used to track
packet order delivery. This field is set to 0 by the ingress PE if
not used and is ignored by the egress PE. The sequence number
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
space is a 16-bit, unsigned circular space. Processing of the
sequence number field is OPTIONAL.
In all cases the egress PE MUST be aware of whether the ingress PE
will send the length and sequence number over a specific Pseudo
Wire.
This may be achieved using static configuration or using Pseudo
Wire specific signaling.
5.1.1 Setting the sequence number
The following procedures SHOULD be used by the ingress PE if
sequencing is desired for a given ATM service:
- 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.
5.1.2 Processing the sequence number
If the egress PE supports receive sequence number processing, then
the following procedures SHOULD 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 SHOULD 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.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
- 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 SHOULD 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.
6 ATM VCC Services
This section defines three types of ATM VCC services that may be
supported over the PSN: ATM cell, ATM AAL5 PDU, and ATM AAL5 SDU.
6.1 ATM VCC Cell Transport Service
The VCC cell transport service is characterized by the mapping of
a single ATM VCC (VPI/VCI) to a Pseudo Wire. This service is
fully transparent to the ATM Adaptation Layer. The VCC cell relay
service is MANDATORY.
This service MUST use the following cell mode encapsulation:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ATM Cell Payload ( 48 bytes ) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Single ATM VCC Cell Encapsulation
* M (transport mode) bit
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
Bit (M) of the control byte indicates whether the packet
contains an ATM cell or a frame payload. If set to 0, the
packet contains an ATM cell. If set to 1, the PDU contains
an AAL5 payload. The ability to transport an ATM cell in the
AAL5 mode is intended to provide a means of enabling OAM
functionality over the AAL5 VCC.
* V (VCI present) bit
Bit (V) of the control byte indicates whether the VCI field
is present in the packet. If set to 1, the VCI field is
present for the cell. If set to 0, no VCI field is present.
In the case of a VCC, the VCI field is not required. For
VPC, the VCI field is required and is transmitted with each
cell.
* Reserved bits
The reserved bits should be set to 0 at the transmitter and
ignored upon reception.
* PTI Bits
The 3-bit Payload Type Identifier (PTI) incorporates ATM
Layer PTI coding of the cell. These bits are set to the
value of the PTI of the encapsulated ATM cell.
* C (CLP) Bit
The Cell Loss Priority (CLP) field indicates CLP value of the
encapsulated cell.
For increased transport efficiency, the ingress PE SHOULD be able
to encapsulate multiple ATM cells into a Pseudo Wire PDU. The
ingress and egress PE SHOULD agree to a maximum number of cells in
a single Pseudo Wire PDU. This agreement may be accomplished via
a Pseudo Wire specific signaling mechanism or via static
configuration.
When multiple cells are encapsulated in the same PSN packet, the
ATM control byte must be repeated for each cell. This implies
that 49 bytes are used to encapsulate each 53 byte ATM cell.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ATM Cell Payload ( 48 bytes ) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|V|Res| PTI |C| |
+-+-+-+-+-+-+-+-+ |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 4: Multiple ATM VCC Cell Encapsulation
6.1.1 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 OAM procedures defined in
[5].
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
- Security
The ingress PE SHOULD be able to generate an F5 AIS upon reception
of a corresponding F4 AIS or lower layer defect (such as LOS).
The egress PE SHOULD be able to generate an F5 AIS based on a PSN
failure (such as a PSN tunnel failure or LOS on the PSN port).
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.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
Upon receiving such a notification, the egress PE SHOULD generate
the appropriate F5 AIS.
6.2 ATM VCC Frame Transport Service
The frame mode services were designed specifically for better
transport efficiency than the cell mode. Two modes of AAL5 frame
transport are available. The transparent AAL5 PDU mode is
intended to be more efficient than cell mode, yet still provide
full ATM transparency including the correct sequencing of OAM
cells on an AAL5 flow. The payload AAL5 SDU mode is intended to
provide transport efficiency than the PDU mode while foregoing
some ATM transparency.
It is important that the PEs be able to efficiently switch between
the frame and cell modes in order to support ATM OAM functions.
The agreement to transport transparent AAL5 PDUs or payload AAL5
SDUs may be accomplished via a Pseudo Wire specific signaling
mechanism or via static configuration.
6.2.1 Transparent AAL5 PDU Frame Service
In this mode, the ingress PE encapsulates the entire CPCS-PDU
including the PAD and trailer.
This mode MAY support fragmentation in order to maintain OAM cell
sequencing.
Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC
service is intended to be more efficient than the VCC cell relay
service. However, the AAL5 transparent VCC service carries the
entire AAL5 CPCS-PDU, including the PAD and trailer. This service
supports all OAM cell flows by using a fragmentation procedure
that ensures that OAM cells are not repositioned in respect to
AAL5 composite cells.
The AAL5 transparent VCC service is OPTIONAL.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|Res|Frg|E|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ " |
| AAL5 CPCS-PDU |
| (n * 48 bytes) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AAL5 transparent service encapsulation
The first octet following the Pseudo Wire Header carries
control information. The M, V, Res, and C bits are as
defined earlier for VCC cell mode.
* Frg (Fragmentation) Bits
This field is used to support the fragmentation functionality
described later in this section.
- 11 Single Segment Message (Beginning and End of Message)
- 10 Beginning of Message
- 00 Continuation of Message
- 01 End of Message
* E (EFCI) bit
This field is used to convey the EFCI state of the ATM cells.
The EFCI state is indicated in the middle bit of each ATM
cell's PTI field.
ATM-to-PSN direction: The EFCI field of the control byte
is set to the EFCI state of the last cell of the AAL5 PDU
or AAL5 fragment.
PSN-to-ATM direction: The EFCI state of all constituent
cells of the AAL5 PDU or AAL5 fragment is set to the value
of the EFCI field in the control byte.
The payload consists of the re-assembled AAL5 CPCS-PDU,
including the AAL5 padding and trailer or the AAL5 fragment.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
6.2.1.1 OAM Cell Support
When configured for the AAL5 transparent VCC service, both PE's
SHOULD act as a VC switch, in accordance with the OAM procedures
defined in [5].
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
- Security
The ingress PE SHOULD be able to generate an F5 AIS upon reception
of a corresponding F4 AIS or lower layer defect (such as LOS).
The egress PE SHOULD be able to generate an F5 AIS based on a PSN
failure (such as a PSN tunnel failure or LOS on the PSN port).
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.
6.2.1.2 Fragmentation
The ingress PE may not always be able to reassemble a full AAL5
frame. This may be due to the AAL5 PDU exceeding the Pseudo Wire
MTU or when OAM cells arrive during reassembly of the AAL5 PDU. In
these cases, the AAL5 PDU shall be fragmented. In addition,
fragmentation may be desirable to bound ATM cell delay.
If no fragmentation occurs, then the fragmentation bits are set to
11 (SSM, Single Segment Message).
When fragmentation occurs, the procedures described in the
following subsections shall be followed.
6.2.1.2.1 Procedures in the ATM-to-MPLS Direction
The following procedures shall apply while fragmenting AAL5 PDUs:
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
- Fragmentation shall always occur at cell boundaries within
the AAL5 PDU.
- For the first fragment, the FRG bits shall be set to 10
(BOM, Beginning Of Message).
- For the last fragment, the FRG bits shall be set to 01 (EOM,
End Of Message).
- For all other fragments, the FRG bits shall be set to 00
(COM, Continuation Of Message).
- The E and C bits shall be set as defined easrlier in section
6.
6.2.1.2.2 Procedures in the MPLS-to-ATM Direction
The following procedures shall apply:
- The 3-bit PTI field of each ATM cell header is constructed
as follows:
+ The most significant bit is set to 0, indicating a
user data cell.
+ The middle bit is set to the E bit value of the
fragment.
+ The least significant bit is set to 1 for the last ATM
cell of a fragment where the FRG bits are 01 (EOM) or
11(SSM); otherwise this bit is set to 0.
- The C bit of each ATM cell header is set to the value of C
bit the control byte.
6.2.2 AAL5 SDU Frame Service
The AAL5 payload VCC service defines a mapping between the payload
of an AAL5 VCC and a single Pseudo Wire. This service is
OPTIONAL.
The AAL5 payload VCC service requires ATM segmentation and
reassembly support on the PE. Once 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. Although
any AAL5 PDU may be transported using the VCC cell relay service
and cell mode encapsulation, the AAL5 payload VCC service is
designed for better transport efficiency.
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
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
are sent immediately on the Pseudo Wire, followed by the AAL5
payload. Therefore, the AAL5 payload VCC service may not be
suitable for some ATM applications that require strict ordering of
OAM cells (such as performance monitoring and security
applications).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN Transport Header (As Required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pseudo Wire Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|R|U|Frg|E|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| AAL5 SDU payload |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AAL5 payload service encapsulation
The first octet following the Pseudo Wire Header carries
control information. The M, V, R (reserved), and C bits are
as defined earlier for VCC cell mode. Since fragmentation is
not required, the fragmentation bits are set to 11 to
indicate a complete frame.
* U (UU Octet Command/Response) Bit
When FRF.8.1 Frame Relay / ATM PVC Service Interworking
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 C bit of
the control byte. The egress PE device SHOULD copy the C bit
to the CPCS-UU Least Significant Bit (LSB) of the AAL5
payload.
6.2.3 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 [5].
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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
- Continuity Check
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 or lower layer defect (such as LOS).
The egress PE SHOULD be able to generate an F5 AIS based on a PSN
failure (such as a PSN tunnel failure or LOS on the PSN port).
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 ATM VPC Services
The VPC service is defined by mapping a single VPC (VPI) to a
Pseudo Wire. As such it emulates as Virtual Path cross-connect
across the PSN. All VCCs belonging to the VPC are carried
transparently by the VPC service.
The egress PE may choose to apply a different VPI other than the
one that arrived at the ingress PE. The egress PE MUST choose the
outgoing VPI based solely upon the Pseudo Wire header. As a VPC
service, the egress PE MUST NOT change the VCI field.
7.1 ATM VPC Cell Transport Services
The ATM VPC cell transport service is OPTIONAL.
This service MUST use the following cell mode encapsulation:
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Single Cell VPC Encapsulation
The ATM control byte contains the same information as in the VCC
encapsulation except for the VCI field.
* VCI Bits
The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
Layer VCI value of the cell.
For increased transport efficiency, the ingress PE SHOULD be able
to encapsulate multiple ATM cells into a Pseudo Wire PDU. The
ingress and egress PE SHOULD agree to a maximum number of cells in
a single Pseudo Wire PDU. This agreement may be accomplished via
a Pseudo Wire specific signaling mechanism or via static
configuration.
When multiple ATM cells are encapsulated in the same PSN packet,
the ATM control byte must be repeated for each cell. This implies
that 51 bytes are used to encapsulate each 53 byte ATM cell.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] |M|V|Res| PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |M|V|Res| PTI |C| VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VCI | |
+-+-+-+-+-+-+-+-+ |
| ATM Cell Payload ( 48 bytes ) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 8: Multiple Cell VPC Encapsulation
7.1.1 OAM Cell Support
When configured for a VPC cell relay service, both PE's SHOULD act
as a VP cross-connect in accordance with the OAM procedures
defined in [5].
The PEs SHOULD be able to pass the following 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
- Security
The ingress PE MUST be able to generate an F4 AIS upon reception
of a lower layer defect (such as LOS).
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
The egress PE SHOULD be able to generate an F4 AIS based on a PSN
failure (such as a PSN tunnel failure or LOS on the PSN port).
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.
8 ATM Port Services
This mode is not required based on the PWE3 requirements draft
[6]. Other design teams (eg Frame Relay) are not considering this
mode of operation. If it is required, the Requirements Draft
should be updated and the following encapsulation may be
considered.
Transparent port encapsulation is used to emulate an ATM Port-to-
Port connection over a PSN. This service is useful when one
desires to connect two CEs without interfering at the VPC or VCC
layer. The ingress PE SHOULD discard any idle/unassigned cells
received from the ingress ATM port, and map all other received
cells to a single Pseudo Wire. A mechanism to discard
idle/unassigned cells received from the ATM port by PE is for
further study.
The egress PE SHOULD not change the VPI, VCI, PTI, or CLP bits
when it sends these cells on the egress ATM port. This service
SHOULD appear as a Layer 1 service (such as SONET/SDH) to CE
devices. However, the service provider may benefit from increased
transport efficiency due to statistical multiplexing.
The transparent port cell relay service is OPTIONAL. It uses the
encapsulation defined below. The agreement to transport this type
of packet may be accomplished via a Pseudo Wire specific signaling
mechanism or via static configuration
For increase transport efficiency, the ingress PE SHOULD be able
to encapsulate multiple ATM cells into a Pseudo Wire PDU. The
ingress and egress PE SHOULD agree to a maximum number of cells in
a single Pseudo Wire PDU. This agreement may be accomplished via
a Pseudo Wire specific signaling mechanism or via static
configuration.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequencing Number ] | Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| ATM Payload ( 48 bytes ) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| ATM Payload ( 48 bytes ) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Port-to-Port mode encapsulation
8.1 OAM Cell Support
This service is completely transparent to the F4 and F5 OAM layer.
The PEs MUST pass all OAM and resource management cells.
If the ingress PE detects a physical layer defect (such as LOS) it
SHOULD be able to notify the egress PE via a mechanism specific to
the Pseudo Wire in use. When it receives such a notification, the
egress PE SHOULD propagate the failure (such as sending a SONET
Line AIS).
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 physical layer AIS.
9 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
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
detection. ILMI messages are sent as SNMP PDU's 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.
10 QoS considerations
TBD.
11 Pseudo-Wire specific requirements
11.1 MPLS requirements
Figure 10 provides a general format for interworking between ATM
and MPLS. The Pseudo Wire Endpoint uses a unique MPLS label, the
pseudo wire label, to identify each direction of an ATM
connection. This label allows the PWE to access context
information for the connection. As an example, the context may
contain the information regarding connection type such as VCC or
VPC or VPI/VCI value that need to be inserted into the ATM cell
header in the MPLS-to-ATM direction.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Transport Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS Pseudo Wire Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Length and Sequence Number ] | ATM Specific |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Service Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format for MPLS PSNs
11.1.1 MPLS Transport Label
The 4-octet MPLS transport label identifies a LSP used to
transport traffic between two ATM-MPLS pseudo wire endpoints. This
label is used to switch the transport LSP between core LSRs.
11.1.2 MPLS Pseudo Wire Label
The 4-octet interworking label uniquely identifies one pseudo wire
LSP, carried inside a MPLS transport LSP. The pseudo wire label
has the structure of a standard MPLS shim header. More than one
pseudo wire LSP may be supported by one MPLS transport LSP. The
pseudo wire endpoint provides the association between the ATM
connection and MPLS LSP by means of the 20-bit field of the pseudo
wire LSP. In this association, in the ATM-to-MPLS direction a
translation of VCI/VPI to the 20-bit label is performed, while in
the MPLS-to-ATM direction the 20-bit label is translated to
VCI/VPI of the ATM connection. This association is signalled or
provisioned between the two pseudo wire endpoints. Since MPLS LSP
is unidirectional, for the case of bi-directional ATM VCCs, there
will be two different pseudo wire LSPs, one for each direction of
the connection. These may have different label values. Setting
of the EXP and TTL is for further study. The S bit is set to 1
since this is the last label in the bottom of the MPLS stack. The
pseudo wire label is not visible to the LSRs within the MPLS core
network.
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
11.2 L2TP requirements
TBD.
11.3 IP requirements
TBD.
12 Security Considerations
This draft does not introduce any new security considerations to
IP, L2TP or MPLS.
13 Intellectual Property Disclaimer
This document is being submitted for use in IETF standards
discussions.
14 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] "Frame Relay / ATM PVC Service Interworking Implementation
Agreement (FRF.8.1)", Frame Relay Forum 2000.
[4] "Frame Based ATM over SONET/SDH Transport (FAST)," ATM Forum
2000.
[5] ITU-T Recommendation I.610 (February 1999): B-ISDN operation
and maintenance principles and functions
[6] IETF draft-ietf-pwe3-requirements-00.txt, work in progress,
(17 May 2001): Requirements for pseudo Wire Emulation Edge-to-
Edge (PWE3)
[7] "Encapsulation Methods for Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-encap-mpls-03.txt, Work in
Progress
[8] "Requirements and framework for ATM network interworking over
MPLS", draft-koleyni-pwe3-atm-over-mpls-02.txt, Work in
Progress
Internet Draft draft-fischer-pwe3-atm-service-00.txt Sept 2001
15 Acknowledgments
16 Authors' Addresses
John Fischer
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: john.fischer@alcatel.com
Matthew Bocci
Alcatel
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel.co.uk
Mina Azad
Nortel Networks
P O Box 3511, Station C
Ottawa, ON, Canada K1Y 4H7
Email: mazad@nortelnetworks.com
Ghassem Koleyni
Nortel Networks
P O Box 3511, Station C Ottawa, Ontario,
K1Y 4H7 Canada
Email: ghassem@nortelnetworks.com
Adeel A. Siddiqui
Cable & Wireless
11700 Plaza America Drive
Reston, Virginia 20190, USA
Email: adeel.siddiqui@cwusa.com