G. Koleyni
B.St-Denis
Internet Draft Nortel Networks
Expiration Date: July 2002 R. Park, M. Aissaoui
J. Fischer, M. Bocci
Alcatel
Sohel Khan
Sprint
Cheng C. Chen
NEC America, Inc.
January 2002
Requirements and framework for ATM network interworking over MPLS
<draft-koleyni-pwe3-atm-over-mpls-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
Generic requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
have been described in [2]. This draft lists ATM specific
requirements and provides encapsulation format 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
Koleyni, et al. Expires July 2002 [Page 1]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
ATM service providers to take advantage of new technologies in the
core to provide ATM multi-services.
Table of contents
1. Introduction 2
2. Terminology 3
3. Background of ATM encapsulation over PSN 4
4. ATM-PSN user plane interworking requirements 6
5. Encapsulation format 6
6. IP Packet Switched Networks User Plane Interworking Aspects
7
7. L2TP Packet Switched Networks User Plane Interworking Aspects
7
8. MPLS Packet Switched Networks User Plane Interworking Aspects
7
8.1. ATM encapsulation format 7
8.2. Encapsulation modes 9
8.2.1 Single cell encapsulation 9
8.2.2 Concatenated cells encapsulation 11
8.2.3 Frame mode encapsulation 13
8.3 Configurable parameters 15
8.4 Fragmentation 15
8.4.1 Procedures in the ATM-to-MPLS direction 16
7.4.2 Procedures in the MPLS-to-ATM direction 16
8.5 ATM OAM and RM Cells 16
8.5.1 ATM-to-MPLS Direction 16
8.5.2 MPLS-to-ATM Direction 17
8.6 Interworking transparency 18
8.6.1 General 18
8.6.2 Specific to Frame Mode Encapsulation 18
9. IP Packet Switched Networks Control Plane interworking Aspects
18
10. L2TP Packet Switched Networks Control Plane interworking Aspects
18
11. MPLS Packet Switched Networks Control Plane interworking Aspects
19
12. IP Packet Switched Networks Management Plane interworking
Aspects 19
13. L2TP Packet Switched Networks Management Plane interworking
Aspects 19
14. MPLS Packet Switched Networks Management Plane interworking
Aspects 19
15. Security Considerations 19
16. References 19
17. Acknowledgement 20
18. Author's Addresses 20
1. Introduction
Koleyni, et al. Expires July 2002 [Page 2]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
Packet Switched Networks (PSNs) have the potential to reduce the
complexity of service provider infrastructures by allowing virtually
any existing digital service to be supported over a single
networking infrastructure. However, many service providers have
legacy network and Operational Support System (OSS) capabilities to
support these existing service offerings. The benefit of PSNs to
this type of network operator is as a common core transport for
multiple existing legacy networks, not as unifying control plane
architecture for all services.
IP, L2TP and MPLS as a common transport infrastructures provide the
ability to transparently carry existing networking systems and the
evolution to a single networking core. The benefit of this model to
the service provider is threefold:
- Leverage of the existing systems and services with increased
capacity from a packet switched core.
- Existing network operational processes and procedures used to
maintain the legacy services are preserved.
- The common packet switched network infrastructure is used to
support both the core capacity requirements of legacy networks
and the requirements of new services, which are supported
natively over the packet switched network.
This draft describes a simple application of ATM encapsulation over
IP, L2TP and MPLS (ATM-PSN interworking). It lists ATM specific
requirements and provides encapsulation format and semantics for
connecting ATM edge networks through a core packet network using IP,
L2TP or MPLS. Encapsulation of various protocols such as ATM, Frame
Relay, Circuit Emulation and Ethernet over MPLS has been discussed
in [11], [12] and [13]. This basic application of ATM interworking
described in this draft will allow ATM service providers to take
advantage of new technologies in the core to provide ATM multi-
services.
2. Terminology
AAL ATM Adaptation Layer
ATMH ATM specific Header
BOM Beginning Of Message
CCM Continuation Of Message
CCM Continuation Of Message
DSL Digital Subscriber Line
EOM End Of Message
L2TP Layer Two Tunneling Protocol
LMDS Local multipoint Distribution System
LSR Label Switching Router
MTU Maximum Transport Unit
NMS Network Management System
OAM Operations, Administration, and Maintenance.
OSS Operational Support System
PCI Protocol Control Information
Koleyni, et al. Expires July 2002 [Page 3]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
PNNI Private Network-Network Interface, An ATM signaling
protocol.
PSN Packet Switched Network
PTI Payload Type Identifier
PVC Permanent Virtual Connection, An ATM connection that is
provisioning via a network management interface. The
connection is not signaled.
PVP Permanent Virtual Path connection, A PVC that is switched
using the ATM VPI.
PWE Pseudo-Wire Endpoint
RM Resource Management, A type of OAM cells.
SE Service Endpoint
SPVC Soft Permanent Virtual Connection, A Soft PVC is
provisioned by the network management system specifying
only the two endpoints of the connection, and having the
connection signaled through the ATM network
SSM Single Segment Message
SVC Switched Virtual Connection
SVP Switched Virtual Path
TLSP Transport LSP
VCC Virtual Circuit Connection, An ATM connection that is
switched based on the cell header's VCI.
VPC Virtual Path Connection, An ATM connection that is
switched based on the cell header's VPI.
Cell Concatenation: The process of bundling a group of cells
belonging to an ATM VCC or a VPC into a packet.
Interworking: Interworking is used to express interactions between
networks, between end systems, or between parts thereof, with the
aim of providing a functional entity capable of supporting an end-
to-end communication. The interactions required to provide a
functional entity rely on functions and on the means to select these
functions. [3]
Interworking Function (IWF): An Interworking Function is a
functional entity that facilitates interworking between two
dissimilar networks (e.g., ATM & MPLS, ATM & L2TP, etc.). A PWE
performs the IWF function.
Network Interworking: In Network Interworking, the PCI (Protocol
Control Information) of the protocol and the payload information
used in two similar networks are transferred transparently by an IWF
of the PWE across the PSN. Typically the
3. Background of ATM encapsulation over PSN
Advances in networking technology in recent years allow service
providers more choice and flexibility in building their networks and
deploying their services. Service providers envision the use of
multiple technologies in their networks, and ATM is often not the
sole technology used in the network core. There exist network
Koleyni, et al. Expires July 2002 [Page 4]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
topologies that rely on packet transport in the core based on IP,
L2TP and MPLS.
In these kinds of network topologies, ATM is present on the edge as
a protocol that brings multi-services into the packet core. Frame
relay services, voice services, and circuit emulation services are
all currently carried over ATM. ATM is also the current underlying
technology for DSL (Digital Subscriber Line) and LMDS (Local
Multipoint Distribution System) access applications. An example of
such a network is shown in Figure 1. ATM connections are carried
transparently over pseudo-wires from one edge of the packet core to
another one (PWE1 to PWE2). The PSNs are primarily used as
transparent tunnels for the pseudo-wires. The role of the
interworking function at each edge of the core is to multiplex a
number of ATM connections (VCCs, VPCs or both) into a pseudo-wire
and originate the pseudo-wire. The pair of pseudo-wires (bi-
directional connectivity) between any two interworking devices at
the edge of the core is either established using a network
management system or is initiated through signaling.
ATM ATM
Multi-services Packet Switched Core Multi-services
Network Network (MPLS) Network
Edge LSR Edge LSR
VCC ************************ VCC
SE ---+-------+------+ Forward LSPs +--------+------+- SE
*=======+=======+=====>*
*<======+=======+======*
SE ---+-------+------+ Backward LSPs +--------+------+- SE
VPC * * VPC
************************
PWE1 PWE2
Figure 1: Example of ATM encapsulation using MPLS as Pseudo-wire
Transparency in this context means that ATM multi-services should be
carried over the packet core unaffected. In other words, the ATM-PSN
interworking function is characterized by:
a. ATM layer protocols are not terminated at the pseudo-wire
endpoints.
b. ATM and PSN user data planes are interworked.
c. ATM control plane information (signaling channels, routing
control channels) and layer management plane information (OAM
cells) are tunneled through the PSN from one pseudo-wire endpoint
to the other pseudo-wire endpoint.
The pair of associated unidirectional paths or pseudo-wires between
the PWEs is seen as a bi-directional link by the ATM edge networks.
Koleyni, et al. Expires July 2002 [Page 5]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
4. ATM-PSN user plane interworking requirements
The following requirements are to complement requirements provided
in [2] to cover ATM encapsulation over PSNs. The ATM Forum has
adopted these requirements as a basis for the development of the
ATM-MPLS network interworking specification [8]:
a. The ability to multiplex multiple ATM connections (i.e., VPCs
and/or VCCS) into a pseudo-wire.
b. Support for the traffic contracts and the QoS commitments made
to the ATM connections (e.g., relationship to underlying MPLS
Diffserv capabilities).
c. The ability to transparently carry all AAL types.
d. The ability to transparently carry all OAM cells, including the
support for proper operation of OAM PM cells and OAM security
cells.
e. Transport of Resource Management (RM) cells.
f. Transport of Cell Loss priority (CLP) and Payload Type
Indicator (PTI) information from the ATM cell header.
g. The ability to encapsulate a single ATM cell within a single
packet with a reasonable overhead.
h. The option to concatenate multiple ATM cells into the same
packet
i. The option to reassemble an AAL5 PDU into one or more packets
for bandwidth efficiency.
5. Encapsulation format
This section describes the general encapsulation format for ATM over
PSN pseudo-wires, IP, L2TP, or MPLS. The specifics pertaining to
each specific packet technology are covered in sections 6, 7 and 8.
Figure 2 provides a general format for encapsulation of ATM cells
(or frames) into packets.
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| PSN Transport Header |
| |
+------+------+------+------+------+------+------+------+
| Pseudo-Wire Header |
| |
+------+------+------+------+------+------+------+------+
| ATM Specific Header |
| |
+------+------+------+------+------+------+------+------+
| ATM Payload |
| |
+------+------+------+------+------+------+------+------+
Figure 2: General format for ATM encapsulation over PSNs
Koleyni, et al. Expires July 2002 [Page 6]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
PSN Transport Header
--------------------
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.
Pseudo Wire Header
------------------
The pseudo-wire header depends on the packet technology: IP, L2TP or
MPLS. It maintains context information associating ATM connection
with the packet technology used.
ATM Specific Header (ATMH)
--------------------------
The ATM Specific Header (ATMH) is inserted before the ATM payload
and identifies whether encapsulation was performed for ATM cells or
AAL5 frames.
ATM Payload
-----------
The ATM payload octet group is the payload of the service that is
being encapsulated.
6. IP Packet Switched Networks User Plane Interworking Aspects
This section is for further study.
7. L2TP Packet Switched Networks User Plane Interworking Aspects
This section is for further study.
8. MPLS Packet Switched Networks User Plane Interworking Aspects
8.1. ATM encapsulation format
Figure 3 provides the format for encapsulation of ATM cells (or
frames) into MPLS packets. The interworking Function (IWF) uses the
PSN Transport header (PSN-TH), to identify each direction of an ATM
connection. This header allows the IWF 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 PSN-
to-ATM direction.
Koleyni, et al. Expires July 2002 [Page 7]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| PSN Transport Header (4 octets) |
| |
+------+------+------+------+------+------+------+------+
| Pseudo-Wire Header (4 octets) |
| |
+------+------+------+------+------+------+------+------+
| ATM Specific Header (1 or 3 octets) |
| |
+------+------+------+------+------+------+------+------+
| ATM Payload |
| |
+------+------+------+------+------+------+------+------+
Figure 3: General format for ATM encapsulation over MPLS
PSN Transport Header
--------------------
This header is used to transport the encapsulated ATM information
through the MPLS core. This header identifies an LSP used to
transport traffic between two ATM-MPLS interworking devices. This
header is visible to the core LSRs, which use it to switch the
transport LSP between core LSRs. The setting of the EXP and TTL
fields of the transport label is outside the scope of this
specification. The S bit is set to 0 for this label, indicating that
this is not the bottom of the label stack.
Pseudo Wire Header
------------------
The 4-octet Pseudo Wire Header uniquely identifies one interworking
LSP, carried inside a MPLS transport LSP. The Pseudo Wire Header has
the structure of a standard MPLS shim header. More than one Pseudo-
wire LSP may be supported by one Transport LSP.
Since a 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.
The IWF maintains the context information that associates the ATM
connection to the MPLS LSP. This information is referenced by means
of the 20-bit label field of the interworking label.
The context of the interworking label field implies:
-Connection type: VCC or VPC.
-VPI value to be inserted in the ATM cells in the MPLS to ATM
direction.
Koleyni, et al. Expires July 2002 [Page 8]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
-For VCC connection types, the VCI value to be inserted in the
ATM cells in the MPLS to ATM direction.
This does not preclude the inclusion of other context information.
Setting of the 20-bit label field is done in the following ways:
ATM-to-MPLS direction
In the case of a VPC, translation of the VPI to the 20 bit label
field is performed. In the case of a VCC, the VPI and VCI are
translated to the 20-bit label field. This association is signaled
or provisioned between a pair of peer IWFs.
The S bit is set to 1 to indicate the bottom of the label stack.
The settings of the EXP and TTL bits are for further study.
MPLS-to-ATM direction
In the case of a VPC, translation of the 20-bit label field to the
VPI is performed. In the case of a VCC, the 20-bit label field is
translated to the VPI and VCI. This association is signaled or
provisioned between a pair of peer IWFs. MPLS frames received with
an invalid or unassigned Pseudo-Wire Header are discarded.
ATM Specific Header (ATMH)
--------------------------
The ATM Specific Header (ATMH) is inserted before the ATM payload
and identifies whether encapsulation was performed for ATM cells or
AAL5 frames. In addition, some elements of the protocol control
information (PCI) constitute parts of this header.
ATM Payload
-----------
The ATM payload octet group is the payload of the service that is
being encapsulated.
8.2. Encapsulation modes
Three modes of encapsulation are considered, Single cell mode,
concatenated cell mode and frame mode.
8.2.1 Single cell encapsulation
In this mode, a single ATM cell is encapsulated in a single packet.
Figure 4 shows structure of the ATM specific header for single ATM
cell encapsulation. Description of ATM specific header fields for
single cell encapsulation is given below:
Koleyni, et al. Expires July 2002 [Page 9]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MODE |VCIP=1| RES | PTI | CLP |
+------+------+------+------+------+------+------+------+
| VCI (2 octets) |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
Figure 4-a (for a VPC)
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MODE |VCIP=0| RES | PTI | CLP |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
Figure 4-b (for a VCC)
Note: bit 0 is the most significant bit
Figure 4: ATM specific header and payload for transport of a single
ATM cell for a VPC and a VCC
MODE (bit 0)
------------
This field is set to 0 to indicate cell mode.
VCI Present (bit 1)
-------------------
This bit is set to 1 when VCI field is present, set to 0 when 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 2 & 3)
---------------------
These bits are reserved for future use. They must be set to 0 when
transmitted and must be ignored upon receipt.
Koleyni, et al. Expires July 2002 [Page 10]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
PTI (bits 4-6)
--------------
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.
CLP (bit 7)
-----------
Cell Loss Priority (CLP) field, which indicates CLP value of the
encapsulated cell is set to the value of the CLP field of the ATM
cell.
VCI: The VCI value, if present, is the same as that of the cell.
Payload: The payload consists of one ATM cell, excluding the header
(i.e., 48 octets).
8.2.2 Concatenated cells encapsulation
Concatenation is the act of encapsulating, one after the other, a
group of cells belonging to the same VCC or VPC into a packet for
more bandwidth efficiency. In the case of a VPC, the concatenated
cells may belong to different VCCs.
The interworking functions at the edge of the ATM-PSN network (i.e.,
PWEs) need to be configured via the NMS (Network Management system)
or via signaling in order to be able to transmit and receive
concatenated cells in a packet. In the case of misconfiguration, a
receiver that is not configured to support cell concatenation might
discard a received payload with a size larger than 48 bytes (i.e.,
payload of a single cell).
Figure 5 shows structure of the ATM specific header for concatenated
cells encapsulation. Description of ATM specific header fields for
concatenated cells encapsulation is given below:
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MODE |VCIP=1| RES | PTI | CLP |
+------+------+------+------+------+------+------+------+
| VCI (2 octets) |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
/ /
/ /
+------+------+------+------+------+------+------+------+
| MODE |VCIP=1| RES | PTI | CLP |
Koleyni, et al. Expires July 2002 [Page 11]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
+------+------+------+------+------+------+------+------+
| VCI (2 octets) |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
Figure 5-a (for a VPC)
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MODE |VCIP=0| RES | PTI | CLP |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
/ /
/ /
+------+------+------+------+------+------+------+------+
| MODE |VCIP=0| RES | PTI | CLP |
+------+------+------+------+------+------+------+------+
/ Payload (48 octets) /
/ /
+------+------+------+------+------+------+------+------+
Figure 5-b (for a VCC)
Note: bit 0 is the most significant bit
Figure 5 ATM specific header and the payload for transport of
concatenated ATM cells of a VPC and a VCC
MODE (bit 0)
------------
This field is set to 0 to indicate cell mode.
VCI Present (bit 1)
-------------------
This bit is set to 1 when VCI field is present, set to 0 when no VCI
field is present. In the case of a VCC, the VCI is not required and
this field is set to 0.
If cell concatenation optimization is disabled (default), then the
VCI field is present for every cell in the MPLS frame. If cell
concatenation optimization is enabled, then the VCI field must be
present in the following cases:
-The cell is the first cell in a MPLS frame
-The previous cell within the MPLS frame belongs to a different
VCC
Koleyni, et al. Expires July 2002 [Page 12]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
REServed (bits 2 & 3)
---------------------
These bits are reserved for future use. They must be set to 0 when
transmitting and must be ignored upon receipt.
PTI (bits 4-6)
--------------
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.
CLP (bit 7)
-----------
Cell Loss Priority (CLP) field, which indicates CLP value of the
encapsulated cell is set to the value of the CLP field of the ATM
cell.
VCI: The VCI value, if present, is the same as that of the cell.
Payload: The total payload consists of up to N (>1) contiguous cells
payloads (i.e., Nx48 octets). The value of N needs to be configured
via the NMS or via signaling. The payload does not include the cell
header. The value of N is limited by the smallest link MTU (Maximum
Transport Unit) in the PSN.
8.2.3 Frame mode encapsulation
This mode is used for carrying a whole AAL5 PDU in the packet. The
whole AAL5 PDU is comprised of its payload, padding, and whole
trailer, which include CPCS-UU (CPCS User-to-User indication), CPI
(Common Part Indicator), Length and CRC (Cyclic Redundancy Check).
ATM cells of an AAL5 PDU are re-assembled and the resulting AAL5 PDU
is encapsulated in a packet.
Figure 6 shows structure of ATM specific header for frame mode
encapsulation. Description of ATM specific header fields for AAL5
frame encapsulation is given below:
0 1 2 3 4 5 6 7
+------+------+------+------+------+------+------+------+
| MODE |VCIP=1| RES | FRAG | EFCI | CLP |
+------+------+------+------+------+------+------+------+
| VCI (2 octets) |
+------+------+------+------+------+------+------+------+
/ Payload /
/ /
+------+------+------+------+------+------+------+------+
Figure 6-a (for a VPC)
0 1 2 3 4 5 6 7
Koleyni, et al. Expires July 2002 [Page 13]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
+------+------+------+------+------+------+------+------+
| MODE |VCIP=0| RES | FRAG | EFCI | CLP |
+------+------+------+------+------+------+------+------+
/ Payload /
/ /
+------+------+------+------+------+------+------+------+
Figure 6-b (for a VCC)
Note: bit 0 is the most significant bit
Figure 6: ATM specific header and the payload for AAL5 frame
transport of VPCs and VCCs
MODE (bit 0)
------------
This field is set to 1 to indicate frame mode.
VCI Present (bit 1)
-------------------
The VCIP bit is set to 1 when VCI field is present, set to 0 when no
VCI field is present.
REServed (bits 2 & 3)
---------------------
These bits are reserved for future use. They must be set to 0 when
transmitted and must be ignored upon receipt.
FRAGmentation (bits 4-5)
------------------------
The FRAG field provides information about frame fragmentation. It is
set to (10 for BOM, Beginning Of Message), (00 for COM, Continuation
Of Message), (11 for SSM, Single Segment Message) and (01 for EOM,
End Of Message). The fragmentation procedures are used to subdivide
the AAL5 PDU into a series of fragments and later reassemble the
sequence of such fragments to reconstitute the original AAL5 PDU.
EFCI (bit 6)
------------
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 ISH is set to the
EFCI state of the last cell of the AAL5 PDU or AAL5 fragment.
Koleyni, et al. Expires July 2002 [Page 14]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
-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 ISH.
CLP (bit 7)
-----------
This field is used to convey the cell loss priority of the ATM
cells.
-ATM-to-PSN direction: The CLP field of the ISH is set to 1 if
any of the constituent cells of the AAL5 PDU or AAL5 fragment
has its CLP bit set to 1; otherwise this field is set to 0.
-PSN-to-ATM direction: The CLP bit of all constituent cells for
an AAL5 PDU or AAL5 fragment is set to the value of the CLP
field in the ISH.
PAYLOAD: The payload consists of the re-assembled AAL5 CPCS-PDU,
including the AAL5 padding and trailer or the AAL5 fragment.
8.3 Configurable parameters
For each ATM connection, the following parameters may be configured:
- Interworking labels (one for each direction)
- Connection type (VCC or VPC)
- Encapsulation mode
- MTU for the transport LSP
- Maximum number of concatenated cells in concatenated cell
mode. This value is limited by the smallest link MTU in the
transport LSP.
- VCIP optimization capability for VPCs in concatenated cell
mode
Some of these parameters need to be agreed by the INEs at either end
of the LSP.
8.4 Fragmentation
This section only applies to frame mode encapsulation.
It may not always be possible to reassemble a full AAL5 frame at an
INE. This may be due to the AAL5 PDU exceeding the MPLS MTU or if
OAM cells arrive during reassembly of an 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 FRAG bits are set to 11 (SSM,
Single Segment Message).
When fragmentation occurs, the procedures described in the following
subsections shall be followed.
Koleyni, et al. Expires July 2002 [Page 15]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
8.4.1 Procedures in the ATM-to-MPLS direction
The following procedures shall apply while fragmenting AAL5 PDUs:
-Fragmentation shall always occur at cell boundaries within the
AAL5 PDU.
-For the first fragment, the FRAG bits shall be set to 10 (BOM,
Beginning Of Message).
-For the last fragment, the FRAG bits shall be set to 01 (EOM,
End Of Message).
-For all other fragments, the FRAG bits shall be set to 00
(COM, Continuation Of Message).
-Setting of the EFCI and CLP fields in the ISH of the fragment
shall be as per Section 8.2.3.
8.4.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 EFCI value of the ISH of
the fragment.
+ The least significant bit is set to 1 for the last ATM
cell of a fragment where the FRAG bits are 01 (EOM) or
11(SSM); otherwise this bit is set to 0.
-The CLP bit of each ATM cell header is set to the value of CLP
field in the ISH.
8.5 ATM OAM and RM Cells
8.5.1 ATM-to-MPLS Direction
Several types of OAM cells are defined in [6]. Applications, such as
those identified in [9], utilize these OAM cells. These cells are
categorized as:
-fault management cells
-performance monitoring and reporting, both in forward and
backward directions
-user OAM cells (e.g. security OAM cells)
At the ATM layer, two types of OAM cell flows are identified: F4
(OAM flow on virtual path level) and F5 (OAM flow on virtual channel
level). F4 and F5 OAM cells are either segment flows for
communicating OAM related information within the boundary of the VPC
or VCC, or end-to-end for information regarding end-to-end VPC or
VCC operations. From an OAM perspective, the INE behaves as an ATM
switch.
OAM cells are always encapsulated with the cell mode encapsulation,
regardless of the encapsulation format for user data.
For cell mode encapsulation of user data, OAM cells are encapsulated
in the same manner as the user data cells.
Koleyni, et al. Expires July 2002 [Page 16]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
For frame mode encapsulation of user data, OAM cells that arrive
during the reassembly of an AAL5 frame cause fragmentation
procedures to be invoked. The partially reassembled AAL5 frame is
sent as a fragment, immediately followed by the OAM cell. Reassembly
of the AAL5 frame is then resumed. If an OAM cell arrives between
AAL5 frames, then it is sent in cell mode encapsulation. This
procedure ensures cell sequence integrity for user cells and OAM
cells.
The general functional architecture of an ATM network element is
provided in Figure 4-2/I.732 of ITU-T Recommendation I.732 [7]. This
functional model is used below to describe the treatment of F4 and
F5 OAM cells at the IWF.
The IWF performs switching at either the VP or the VC level. In the
following sections, frame mode encapsulation refers to the
encapsulation method for user data.
VP Switching - Cell Mode Encapsulation
F4 OAM cells are inserted or extracted by the INE. These cells are
then sent across the LSP according to procedures specified in [6].
F5 OAM are not inserted or extracted here and are therefore simply
encapsulated and sent across the LSP.
VP Switching - Frame Mode Encapsulation
This case is not supported by this specification.
VC Switching - Cell Mode Encapsulation
F4 OAM cells are inserted or extracted at the VP link termination;
such OAM cells are not seen at the VC link termination and are
therefore not sent across the LSP. F5 OAM cells are inserted or
extracted at the VC link termination or VC termination. These cells
are then sent across the LSP according to procedures specified in
[6].
VC Switching - Frame Mode Encapsulation
This case is the same as _VC switching _ Cell Mode Encapsulation_.
RM cells use a PTI value of 110 [6] and are treated the same way as
OAM cells in order to maintain cell ordering.
8.5.2 MPLS-to-ATM Direction
Koleyni, et al. Expires July 2002 [Page 17]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
OAM and RM cells are received as single encapsulated cells. They are
treated at the INE in accordance with procedures described in [6],
[7] and [9].
8.6 Interworking transparency
An objective of this specification is to provide complete
transparency for ATM services across the interworking function. Due
to the nature of interworking across frame-based networks, several
limitations are unavoidable.
The MPLS network is assumed to maintain frame sequence ordering
between the sending IWF and the receiving IWF in steady state
operation. Some applications are sensitive to the mis-ordering of
user and OAM cells. (e.g. those described in [9]). Mechanisms for
the detection of frames that are mis-ordered by the MPLS network are
for further study.
The cell loss ratio may be adversely affected by transport across
the MPLS network. An MPLS frame may be discarded due to a single bit
error within the entire MPLS frame. By contrast, a separate HEC
field protects ATM cell headers. Thus, ATM cells can be switched
even if errors occur in the cell payload.
An IWF has an implementation-specific contribution to the end-to-end
maximum CTD and peak-to-peak CDV, when these parameters are
specified for an ATM connection. The INE applies its contribution to
the accumulated end-to-end values as specified in TM4.1 [10]. Once
the connection is established, the IWF's contribution to the maximum
CTD and peak-to-peak CDV shall not exceed the values previously
advertised. Note that the INE contribution includes the time
required for cell concatenation (cell encapsulation mode) or AAL5
PDU reassembly (frame encapsulation mode).
8.6.2 Specific to Frame Mode Encapsulation
This mode does not preserve the value of the CLP bit for every ATM
cell within an AAL5 PDU. Therefore, transparency of the CLP setting
may be violated. Additionally, tagging of some cells may occur when
tagging is not allowed by the conformance definition [10].
This mode does not preserve the EFCI state for every ATM cell within
an AAL5 PDU. Therefore, transparency of the EFCI state may be
violated.
9. IP Packet Switched Networks Control Plane interworking Aspects
This section is for further study.
10. L2TP Packet Switched Networks Control Plane interworking Aspects
Koleyni, et al. Expires July 2002 [Page 18]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
This section is for further study.
11. MPLS Packet Switched Networks Control Plane interworking Aspects
Transport of ILMI, control signaling and control routing requires
configuration of the interworking labels to be used for each of
these virtual connections. This is for further study.
12. IP Packet Switched Networks Management Plane interworking Aspects
This section is for further study.
13. L2TP Packet Switched Networks Management Plane interworking Aspects
This section is for further study.
14. MPLS Packet Switched Networks Management Plane interworking Aspects
ATM OAM cells carry performance, fault, security and protection
switching information for VCCs and VPCs on an end-to-end and segment
basis [6] to support ATM layer management functions. The
interworking function shall be capable of transferring ATM OAM
information through the MPLS network by encapsulating ATM OAM cells
in MPLS frames. In addition, the interworking function may
correlate MPLS OAM information with ATM OAM information in the
management plane through internal or external management interfaces.
Correlation of MPLS OAM information and ATM OAM cells is for further
study. This is for further study.
15. Security Considerations
This draft does not introduce any new security considerations to IP,
L2TP or MPLS.
16. References
[1] IETF RFC 2026 (October 1996): The Internet Standards Process-
Revision 3, BCP 9
[2] IETF draft-ietf-pwe3-requirements-01.txt, work in progress,
(July 2001): Requirements for pseudo Wire Emulation Edge-to-
Edge (PWE3)
[3] ITU-T Recommendation I.510 (March 1993): Definitions and
general principles for ISDN interworking
[4] IETF RFC 3032 (January 2000): MPLS Label Stack Encoding
[5] ITU-T Recommendation I.361 (February 1999): B-ISDN ATM layer
specification
[6] ITU-T Recommendation I.610 (February 1999): B-ISDN operation
and maintenance principles and functions
[7] ITU-T Recommendation I.732 (March 1996): Functional
characteristics of ATM equipment
Koleyni, et al. Expires July 2002 [Page 19]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
[8] ATM Forum, FB-AIC-0178.000 (August 2001), ATM-MPLS Network
Interworking
[9] ATM Forum specification af-sec-0100.002 (March 2001): ATM
Security Specification Version 1.1
[10] ATM Forum specification af-tm-0121.000 (March 1999): Traffic
Management Specification Version 4.1
[11] IETF draft draft-martini-12circuit-encap-mpls-02.txt, work in
progress, (May 2001): Encapsulation methods for transport of
layer 2 frames over MPLS
[12] IETF draft draft-martini-12circuit-trans-mpls-06.txt, work in
progress, (May 2001): Transport of layer 2 frames over MPLS
[13] IETF draft draft-stdenis-ms-over-mpls-00.txt, work in progress,
(Nov 2000): Multi-service over MPLS
[14] IETF draft-pate-pwe3-framework-01.txt, work in progress, (July
2001): Framework for pseudo Wire Emulation Edge-to-Edge (PWE3)
17. Acknowledgement
The authors like to acknowledge the contribution to this work by Dr.
Khalid Ahmad.
18. Author's Addresses
Ghassem Koleyni
Nortel Networks
P O Box 3511, Station C Ottawa, Ontario,
K1Y 4H7 Canada
Email: ghassem@nortelnetworks.com
Bernard St-Denis
Nortel Networks
P O Box 3511, Station C Ottawa, Ontario,
K1Y 4H7 Canada
Email: bernie@nortelnetworks.com
Robin Park
Alcatel Networks Corporation
600 March Road
Kanata, Ontario,
K2K 2E6 Canada
Email: robin.park@alcatel.com
Mustapha Aissaoui
Alcatel Networks Corporation
600 March Road
Kanata, Ontario,
K2K 2E6 Canada
Email: mustapha.aissaoui@alcatel.com
Matthew Bocci
Alcatel Telecom Ltd.
Koleyni, et al. Expires July 2002 [Page 20]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks,
UK SL6 2PJ
Email: Matthew.bocci@alcatel.com
John Fischer
Alcatel Networks Corporation
600 March Road
Kanata, Ontario,
K2K 2E6 Canada
Email: john.fischer@alcatel.com
Sohel Khan
Sprint
7171 W 95th Street
Overland Park, KS 66212
Email: sohel.khan@mail.sprint.com
Cheng C. Chen
Network Systems Division,
NEC America, Inc.
6555 N. State Highway 161,
Irving, TX 75039
Email: cchen@necam.com
Koleyni, et al. Expires July 2002 [Page 21]
Internet Draft draft-koleyni-pwe3-atm-over-mpls-04.txt January 2002
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Koleyni, et al. Expires July 2002 [Page 22]