One document matched: draft-davari-pwe3-aal12-over-psn-01.txt
Differences from draft-davari-pwe3-aal12-over-psn-00.txt
Shahram Davari
Internet Draft PMC-Sierra Inc.
Document:
draft-davari-pwe3-aal12-over-psn-01.txt
Expires: September 2003 March 2003
Transport of AAL1 frames over PSN
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright(C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes methods for transporting AAL1 over IP/MPLS
network, using the existing ATM transport over IP/MPLS methods
described in [ATM-encap].
Sub-IP ID Summary
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK?
Fits in the PE box
WHY IS IT TARGETED AT THIS WG?
It proposes ATM AAL1 transport over PSN network such as IP/MPLS
network.
Davari Expires September 2003 Page 1
Transport of AAL1 frames over PSN March 2003
JUSTIFICATION?
The PWE3 WG charter calls for ATM and TDM emulation over PSN. [ATM-
encap] covers the ATM cell transport and the AAL5 frame transport
over PSN. This draft complements [ATM-encap] and explains how to
transport AAL1 traffic over PSN using the already defined methods
and options in [ATM-encap] without introducing any new protocol.
Table of contents
1. Conventions used in this document.............................2
2. Introduction..................................................2
3. Applicability.................................................3
4. Implementation and deployment consideration...................3
5. Limitations...................................................4
6. AAL1 transport using N:1 cell mode............................4
7. AAL1 transport using 1:1 cell mode............................5
8. AAL1 transport using PDU mode.................................6
9. Length and sequence number....................................9
10. Administrative (OAM and RM) Cell Support.....................10
11. Defect Handling..............................................10
12. QoS consideration............................................11
13. AAL1 over IP/MPLS specific requirements......................12
14. Security.....................................................12
15. References...................................................12
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. Introduction
Currently a great portion of voice and TDM traffic is carried over
ATM networks using AAL1 adaptation layer. As the service providers
migrate to IP/MPLS networks there is a need to transport AAL1
traffic over IP/MPLS networks.
This document describes methods for transporting AAL1 over IP/MPLS
networks, using the ATM transport modes described in [ATM-encap]
without introducing any new protocol. This document extends the
applicability of equipments that implement [ATM-encap], to
transporting AAL1 traffic and potentially enables transport of TDM
circuit emulation traffic over IP/MPLS networks as explained in
[draft-anavi].
Davari Expires August 2003 Page 2
Transport of AAL1 frames over PSN March 2003
Note 1: Throughout this document, ôfragmentationö means PDU
fragmentation procedures as described in [ATM-encap].
Note 2: Throughout this document, AAL1 PDU means the 48-byte AAL1
SAR-PDU as described in [ITU-AAL1].
Note 3: Since SDU mode is explicitly designed only for AAL5
transport; it cannot be used to transport AAL1.
3. Applicability
The primary applications supported by AAL1 transport over PSN are
CBR services such as voice and TDM services.
The AAL1 transport takes advantage of the N:1 cell mode, described
in [draft-martini,] to provide a default standard method for
carrying AAL1 traffic. In addition it optionally also takes
advantage of 1:1 cell mode and PDU mode, described in [ATM-encap],
to increase bandwidth efficiency. The nature of the service, as
defined by the [ATM service] or the [ATM transfer capability] should
be preserved. To provide this, the basic requirement of the ATM-PSN
interworking function is to map the AAL1 PDU frames belonging to a
VCC, together with any related OAM, RM cells and protocol control
information, into a PW.
The benefits of this model to service providers and vendors are:
i. Leveraging existing systems and services to provide
increased capacity from a packet switched core.
ii. Preserving existing network operational processes and
procedures used to maintain the legacy services e.g. AAL1,
ATM OAM and ATM security.
iii. 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.
iv. Leveraging the same hardware and software used for
transporting ATM over IP/MPLS networks to transport AAL1
and TDM signals over those networks.
v. Leveraging off the shelf hardware and software that emulate
TDM over AAL1 to transport TDM signals over IP/MPLS
network.
4. Implementation and deployment consideration
The procedures mentioned in this draft, apply in most part to any
ATM AAL type, but the scope of this draft is the AAL1 frame
transport over a PSN. It leverages the modes and options already
defined in [ATM-encap] and does not introduce any new protocol, and
therefore is backward compatible with hardware and software
developed for Martini-compliant equipments.
Davari Expires August 2003 Page 3
Transport of AAL1 frames over PSN March 2003
For bandwidth efficiency reasons the AAL1 frame transport may use
PDU mode. To take advantage of the PDU mode, the fragmentation
procedure for bounding cell transfer delay as described in [ATM-
encap] MUST be used. This means that the ingress PE MUST have the
PDU fragmentation capability that will limit the payload size of the
IP/MPLS packet to Nx48 bytes, in which N is a pre-configured value
that bounds the cell transfer delay.
Since services that use AAL1, such as circuit emulation service,
expect in-order delivery of data, for the purpose of AAL1 transport,
it is advantageous to use the control wordÆs Sequence number.
However, sequence number usage is optional as per [ATM-encap].
5. Limitations
AAL1 frame transport only supports point-to-point LSPs. Multi point-
to-point and point-to-multi-point are for further study (FFS).
To have bi-directional connectivity, as required in ATM, two LSPs
should be configured, one for each direction (ATM-to-MPLS and MPLS
to-ATM) of the ATM connection.
This draft does not preserve the value of the CLP bit for every ATM
cell. 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.
This draft does not preserve the EFCI state for every ATM cell.
Therefore, transparency of the EFCI state may be violated.
6. AAL1 transport using N:1 cell mode
N:1 cell mode is the only default and mandatory mode described in
[ATM-encap]. To be fully compliant with [ATM-encap], this document
also recommends the N: 1 cell mode as the default mode for
transporting AAL1 traffic over IP/MPLS networks.
Using N: 1 cell mode, one or more AAL1 stream could be transported
over a single PW. Individual AAL1 streams are differentiated from
each other by the VPI/VCI that is carried with each cell.
The following figure shows how multiple CBR streams could be
transported over a single PW using N:1 cell mode.
+----+ +---+ +-------+
CBR stream 1 --->| |---->| | | |
CBR stream 2 --->|AAL1|---->|ATM|--->| N:1 |---> PW1
CBR stream 3 --->| |---->| | | Mode |
+----+ +---+ +-------+
Davari Expires August 2003 Page 4
Transport of AAL1 frames over PSN March 2003
Figure 1: AAL1 transport over PSN using Martini N: 1 cell mode
In this figure CBR streams are attached to an AAL1 block. The AAL1
block performs the AAL1 adaptation function as specified in [ITU
AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The
ATM block performs the ATM layer functions by adding 5-byte ATM
headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1
stream is assigned a unique VPI/VCI based on the interface at which
it arrives to the ATM block. The ATM block then generates an ATM
stream toward a Martini (N:1) block, which then transports the ATM
cells over a single PW (PW1), according to the N:1 cell mode of
[ATM-encap]. Each IP/MPLS packet may carry one or more cells
belonging to one or more AAL1 streams.
The AAL1 and ATM blocks could be located in the CE or in the PE. If
they are in CE, then the link between CE-PE is an ATM link, while if
they are in PE, then the link between CE-PE is a TDM link.
7. AAL1 transport using 1:1 cell mode
1:1 cell mode is an optional mode described in [ATM-encap], and is
more bandwidth efficient than N:1 cell mode. To be fully compliant
with [ATM-encap], this document also permits the usage of 1:1 cell
mode as an optional mode for transporting AAL1 traffic over IP/MPLS
networks.
Using 1:1 cell mode, only one AAL1 stream could be transported over
a single PW. Individual AAL1 streams are differentiated from each
other by the PW that they are carried in.
The following figure shows how a single AAL1 stream could be
transported over a single PW using 1:1 cell mode.
+----+ +---+ +-------+
CBR stream 1 --->| |---->| | | |---> PW1
CBR stream 2 --->|AAL1|---->|ATM|--->| 1:1 |---> PW2
CBR stream 3 --->| |---->| | | Mode |---> PW3
+----+ +---+ +-------+
Figure 2: AAL1 transport over PSN using Martini 1: 1 cell mode
In this figure CBR streams are attached to an AAL1 block. The AAL1
block performs the AAL1 adaptation function as specified in [ITU
AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The
ATM block performs the ATM layer functions by adding 5-byte ATM
headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1
stream is assigned a unique VPI/VCI based on the interface that it
arrives to the ATM block. The ATM block then generates an ATM stream
toward a Martini (1:1) block, which then transports the ATM cells
over multiple PWs (PW1, PW2, PW3) bases on their VPI/VCI, according
Davari Expires August 2003 Page 5
Transport of AAL1 frames over PSN March 2003
to the 1:1 cell mode of [ATM-encap]. Each IP/MPLS packet may carry
one or more cells belonging to the same AAL1 stream.
The AAL1 and ATM blocks could be located in the CE or in the PE. If
they are in CE, then the link between CE-PE is an ATM link, while if
they are in PE, then the link between CE-PE is a TDM link.
8. AAL1 transport using PDU mode
PDU mode is an optional mode described in [ATM-encap], and is more
bandwidth efficient than either 1:1 and N:1 cell modes. PDU mode was
originally designed to carry AAL5 PDUs. However, it does not
prohibit using it to carry other AAL types. The technique can easily
be employed for other AAL types including AAL1. This is shown in
section 8.1.
To be fully compliant with [ATM-encap], this document also permits
using the PDU mode as an optional mode for transporting AAL1 traffic
over IP/MPLS networks.
Using PDU mode, only one AAL1 stream could be transported over a
single PW. Individual AAL1 streams are differentiated from each
other by the PW that they are carried in. In this mode, the ingress
PE encapsulates one or more AAL1-PDUs (Nx48 bytes) belonging to the
same AAL1 stream in a single packet.
The following figure shows how a single AAL1 stream could be
transported over a single PW using PDU mode.
+----+ +---+ +-------+
CBR stream 1 --->| |---->| | | |---> PW1
CBR stream 2 --->|AAL1|---->|ATM|--->| PDU |---> PW2
CBR stream 3 --->| |---->| | | Mode |---> PW3
+----+ +---+ +-------+
Figure 3: AAL1 transport over PSN using PDU mode
In this figure CBR streams are attached to an AAL1 block. The AAL1
block performs the AAL1 adaptation function as specified in [ITU
AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The
ATM block performs the ATM layer functions by adding 5-byte ATM
headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1
stream is assigned a unique VPI/VCI based on the interface that it
arrives to the ATM block. The ATM block then generates an ATM stream
toward a Martini (PDU) block, which then transports the ATM cells
over multiple PWs (PW1, PW2, PW3) bases on their VPI/VCI, according
to the PDU mode of [ATM-encap]. Each IP/MPLS packet may carry one or
more cells belonging to the same AAL1 stream.
Davari Expires August 2003 Page 6
Transport of AAL1 frames over PSN March 2003
The AAL1 and ATM blocks could be located in the CE or in the PE. If
they are in CE, then the link between CE-PE is an ATM link, while if
they are in PE, then the link between CE-PE is a TDM link.
It can be seen from Figure 3 that the ATM block adds the ATM header
to each AAL1-PDU, while Martini (PDU) block removes the ATM headers
and encapsulates Nx48 byte payloads (AAL1-PDUs) in to IP/MPLS
packet. In case the the ATM block and the Martini block are
implemented in a single PE device it is possible to combine them and
therefore reduce the required processing by eliminating the
add/remove ATM header operations. This concept is shown in the
following figure.
+----+ +----------+
CBR stream 1 --->| |---->|simplified|---> PW1
CBR stream 2 --->|AAL1|---->| PDU mode |---> PW2
CBR stream 3 --->| |---->| |---> PW3
+----+ +----------+
Figure 4: AAL1 transport over PSN using simplified PDU mode
In this figure AAL1 streams are attached to a simplified PDU mode
block. This block performs all the PDU mode operations except the
ATM header removal. The AAL1 streams contain 48-byte AAL1-PDUs. The
simplified Martini (PDU) block, transports the AAL1 PDUs over
multiple PWs (PW1, PW2, PW3) bases on their input port, according to
the PDU mode of [ATM-encap]. Each IP/MPLS packet may carry one or
more cells belonging to the same AAL1 stream.
8.1 How to use PDU mode to transport AAL1
Although PDU mode is designed to transport AAL5 frames, it does not
prohibit carrying other AAL type traffic. As it turns out, after a
small change that was made to the PDU mode by the ATM Forum, the PDU
mode could actually be used to carry other AAL types, including
AAL1.
ATM Forum noted that the current PDU mode is structured so that it
requires reassembly of fragments at the egress PE. However, it was
recognized that not only such a reassembly is not necessary, but
also is harmful. For example reassembling the fragments may cause
the OAM/RM cells to be misplaced in the stream. Also reassembly of
fragments would increase the cost of buffering and the overall
delay. These coupled with the fact that almost all implementations
of PDU mode donÆt actually reassemble the fragments, triggered a
minimal change to the PDU mode to rectify the situation.
The ATM Forum decided to change the 2-bit FRAG field in the
Interworking header to a Reserved bit followed by a UU-bit (Figure
5). The UU-bit would be copied from the MSB of the PTI of the last
encapsulated cell to this field. This change simplifies the egress
Davari Expires August 2003 Page 7
Transport of AAL1 frames over PSN March 2003
processing as well as opening new opportunities, such as using the
PDU mode to transport other AAL types, including AAL1.
Looking at the operation of PDU mode, we would see that what it
actually does is to concatenate a number of 48-byte ATM payloads in
a packet and send it across the PSN. The concatenation would
terminate when either the UU bit=1 (used to indicate end of packet
in AAL5), or when an RM/OAM cell arrives or when the packetization
delay limit has exceeded.
The same procedure when applied to AAL1 stream would concatenate a
number of AAL1-PDUs (48-byte) in a packet and send it across the
PSN. The concatenation would terminate when either RM/OAM cells
arrive or when packetization delay limit is exceeded. Since AAL1
does not use the UU-bit, the UU-bit processing has no impact on it.
The following figure shows the format of the packet generated by PDU
mode (when the ATM Forum changes are reflected) for AAL1 transport.
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 |M|V| RES |U|E|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| AAL1 PDUs |
| (N * 48 bytes) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AAL1 transport over PDU encapsulation format
The first octet following the Pseudo Wire Header carries control
information. The M, V, RES, U, E and C bits are defined as
following:
* M (Mode) bit
This bit is set to æ1Æ to indicate the frame mode encapsulation
* V (VCI present) bit
This bit is set to æ0Æ to indicate that no VCI is present
* RES (Reserved) bits
Davari Expires August 2003 Page 8
Transport of AAL1 frames over PSN March 2003
These bits are reserved in [ATM-encap] and by default are set
to æ000Æ. However for the purpose of transporting AAL1 they MAY
be used to encode L & R values as described in section 11.1.
* UU bit
This field is used to transparently carry the UU-bit of the last
encapsulated cell in the packet. Since it is not used by AAL1 its
value would be set to æ0Æ.
* 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 (ingress): The EFCI field of the control
byte is set to the EFCI state of the last cell of the packet.
PSN-to-ATM direction (egress): The EFCI state of all
constituent cells of the packet are set to the value of the
EFCI field in the control byte.
* C (CLP) bit
This field is used to convey the cell loss priority of the ATM
cells.
ATM-to-PSN direction (ingress): The CLP field of the control
byte is set to æ1Æ if any of the constituent cells of the
packet has its CLP bit set to æ1Æ; otherwise this field is set
to æ0Æ.
PSN-to-ATM direction (egress): The CLP bit of all constituent
cells of a packet is set to the value of the CLP field in the
control byte.
As shown in figure 5, N x AAL1 PDUs (Nx48 bytes) are packed in a
single IP/MPLS packet to form the payload of the PW packet. The PDUs
are formed by removing the ATM header of arriving cells. N SHOULD be
either configured or negotiated between PEs based on the maximum
delay tolerance and maximum MTU size.
9. Length and sequence number
PDU mode [ATM-encap] requires the inclusion of Length field for
links that have a minimum frame size, such as Ethernet with a
minimum frame size of 64 octets. The same requirement exists for
AAL1 transport over PDU mode.
The use of sequence number is optional in [ATM-encap]. For the
purpose of transporting AAL1 PDUs, here too the use of sequence
number is optional. However, it should be noted that since the AAL1
Davari Expires August 2003 Page 9
Transport of AAL1 frames over PSN March 2003
is mainly used for CBR applications, such as circuit emulation that
expect in-order delivery with no loss, it is advantageous to use
sequence number. For example by using sequence number in the circuit
emulation, the receiver could detect lost packets and insert dummy
payload to keep the TDM frame synchronization.
The procedure for generation and processing of Length and Sequence
number are the same as those defined in [ATM-encap].
10. Administrative (OAM and RM) Cell Support
The treatment of OAM and RM cells is as per [ATM-encap], and depends
on the transport mode selected.
11. Defect Handling
For the purpose of detection and handling of defects that may occur
in the PSN, the PSN should normally have its own OAM (operation and
maintenance) and defect handling mechanism. These mechanisms are
outside the scope of this draft.
There are some defects that may occur outside of the PSN, such as
defects at a lower layer (e.g. Physical layer LOS) between CE-PE.
These defects are detected by other means than PSN OAM. When such
defect happens, the PE SHOULD generate ATM F5 AIS on all affected
VCs according to [ATM-encap].
When an ingress PE cannot support the generation of F5 OAM cells
upon reception of a corresponding F4 AIS or lower layer defect (such
as LOS), it MAY notify the egress PE by setting the L-bit (as
defined below) in the control byte to indicate that a defect exist
at a lower layer (i.e., Physical layer) in the ATM-to-PSN direction.
In such defect conditions, the packet payload is meaningless. For
bandwidth saving purpose, the IP/MPLS packets MAY be send with
minimum PSN payload set to all zeros.
For AAL1 services, loss of packets is an important defect that MAY
be detected and reported. Loss of packet could be due to
connectivity failure of congestion. In either case Egress PE MAY use
sequence number in the control word (figure 1) to detect packet
loss. Upon detection of such a packet loss the egress PE MAY inform
the ingress PE by setting the R-bit (as defined below) in the
control byte to indicate a packet loss. The ingress PE could use
that information to shut down or reroute the PW. Loss of
connectivity MAY alternatively be detected independently using PSN
specific OAM mechanisms.
11.1 L & R bits
3 bits are reserved (RESV bits) in [ATM-encap] (assuming ATM Forum
change on PDU mode has been accepted) for future use. [ATM-encap]
requires that these bits be set to zero at ingress PE and ignored at
Davari Expires August 2003 Page 10
Transport of AAL1 frames over PSN March 2003
reception. This draft proposes encoding the forward and backward
defect identifiers in two of these reserved bits as following.
L-bit: Forward defect identifier. L-bit is the left hand bit of the
RESV field in the control byte. It MAY be set when a failure happens
in a lower layer between CE-PE and the ingress PE cannot support the
generation of OAM cells upon reception of a corresponding F4 AIS or
lower layer defect (such as LOS). It SHOULD be cleared when those
failures are rectified.
R-bit: Backward defect identifier. R-bit is the right hand bit of
the RESV field in the control byte. It MAY be set after a PE detects
loss of a pre-configured number of packets in a certain interval.
And it should be cleared after reception without loss of a pre-
configured number of packets.
The PEs that canÆt or donÆt want to encode L or R bits in the RESV
field will set them to æ0Æ as per [ATM-encap]. The PEs that canÆt
interpret the L or R bits will ignore the RESV field as per [ATM-
encap]. These rules insure backward compatibility with equipments
that have already been developed based on PDU mode. The following
figure shows the encoding of L & R bits.
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 |M|V|L|R| |U|E|C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| " |
| AAL1 PDUs |
| (N * 48 bytes) |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: L & R bit encoding in PDU encapsulation format
12. QoS consideration
Since AAL1 is predominantly used to transport real-time CBR data,
such as TDM traffic, it is recommended to provision enough BW to
carry the AAL1 traffic. In case Diffserv is used it is recommended
to use a virtual wire kind of PDB to transport the AAL1 PDUs over
the PSN.
Davari Expires August 2003 Page 11
Transport of AAL1 frames over PSN March 2003
13. AAL1 over IP/MPLS specific requirements
All the requirements of [ATM-encap] apply also to this draft.
14. Security
No additional security risk apart from the security risks associated
with IP/MPLS networks issues are introduced in this document.
15. References
[ATM-encap] draft-ietf-pwe3-atm-encap.txt (Feb 2003, work in
progress), Encapsulation Methods for Transport of ATM Cells/Frame
Over IP and MPLS Networks
[ATM service] ATM Forum Specification af-tm-0121.000 (1999), Traffic
Management Specification Version 4.1.
[ATM transfer capability] ITU-T Recommendation I.371 (2000), Traffic
control and congestion control in B-ISDN.
[ATM OAM] ITU-T Recommendation I.610, (1999), B-ISDN operation and
maintenance principles and functions.
[ITU-AAL1] ITU-T Recommendation I.363.1, (1996), B-ISDN ATM
Adaptation Layer specification: Type 1 AAL
[draft-anavi] draft-anavi-tdmoip-05.txt (March 2003, work in
progress), TDM over IP
AuthorsÆ Address
Shahram Davari
PMC-Sierra
555 Legget Drive Phone: 1-613-271-4018
Kanata, ON, K2K 3C9, Email: Shahram_Davari@pmc-sierra.com
Canada
Davari Expires August 2003 Page 12
| PAFTECH AB 2003-2026 | 2026-04-21 11:38:00 |