Network Working Group M. Riegel
Internet-Draft Siemens AG
Expires: December 17, 2002 A. Vainshtein
Axerra Networks
Y. Stein
RAD Data Communications
P. Pate
Overture Networks, Inc.
June 18, 2002
Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet
Switching Networks (PSN)
draft-riegel-pwe3-tdm-requirements-00.txt
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.
This Internet-Draft will expire on December 17, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies the particular requirements for edge-to-
edge-emulation of circuits carrying time division multiplexed (TDM)
digital signals over packet-switched networks. It is based on the
common framework of PWE3 as defined in [PWE3-FW] and the
considerations on protocol layering in PWE3 as discussed in [PWE3-
Riegel, et al. Expires December 17, 2002 [Page 1]
Internet-Draft PWE3 TDM Requirements June 2002
LAYERS].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining additional requirements
originating from specifics of TDM circuits.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Reference Models . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Generic PWE3 Models . . . . . . . . . . . . . . . . . . . . 6
4.2 Network Synchronization Reference Model . . . . . . . . . . 6
4.2.1 Synchronous Network scenarios . . . . . . . . . . . . . . . 9
4.2.2 Asynchronous Carrier of Carriers scenario . . . . . . . . . 9
5. Emulated Services . . . . . . . . . . . . . . . . . . . . . 10
5.1 Structured TDM Circuits . . . . . . . . . . . . . . . . . . 10
5.2 Unstructured TDM Circuits . . . . . . . . . . . . . . . . . 10
6. Generic Requirements . . . . . . . . . . . . . . . . . . . . 11
6.1 Relevant Common PW Requirements . . . . . . . . . . . . . . 11
6.2 Common Circuit Payload Requirements . . . . . . . . . . . . 12
6.3 General Design Issues . . . . . . . . . . . . . . . . . . . 12
7. Service-Specific Requirements . . . . . . . . . . . . . . . 13
7.1 Interworking . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Network Synchronization . . . . . . . . . . . . . . . . . . 13
7.3 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3.1 Packet loss . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3.2 Out-of-order delivery . . . . . . . . . . . . . . . . . . . 14
7.4 CE Signaling . . . . . . . . . . . . . . . . . . . . . . . . 14
7.5 PSN bandwidth utilization . . . . . . . . . . . . . . . . . 15
7.6 Packet Delay Variation . . . . . . . . . . . . . . . . . . . 15
7.7 Compatibility with the Existing PSN Infrastructure . . . . . 16
7.8 Congestion Control . . . . . . . . . . . . . . . . . . . . . 16
7.9 Fault Detection and Handling . . . . . . . . . . . . . . . . 16
7.10 Performance Monitoring . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . 20
Riegel, et al. Expires December 17, 2002 [Page 2]
Internet-Draft PWE3 TDM Requirements June 2002
1. Introduction
This document specifies the particular requirements for edge-to-edge-
emulation of circuits carrying time division multiplexed (TDM)
digital signals over packet-switched networks. It is based on the
common framework of PWE3 as defined in [PWE3-FW] and the
considerations on protocol layering in PWE3 as discussed in [PWE3-
LAYERS].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining additional requirements
originating from specifics of TDM circuits.
Circuits carrying TDM signals have been defined in such normative
documents as [G.703], [G.704] and [T.107].
To support TDM traffic, which includes voice, data, and private
leased line service, the network must emulate the circuit
characteristics of a TDM network.
Riegel, et al. Expires December 17, 2002 [Page 3]
Internet-Draft PWE3 TDM Requirements June 2002
2. Motivation
[PWE3-REQ] specifies common requirements for edge-to-edge-emulation
of circuits of various types. However, these requirements, as well
as references in [PWE3-FW] and [PWE3-LAYERS] do not fully cover all
specifics of PWs carrying TDM circuits.
The need for a specific document complementing [PWE3-REQ] with regard
to edge-to-edge-emulation of TDM circuits arises from following
causes:
o Specifics of the TDM circuits,
e.g.:
* the need for balance between the clock of ingress and egress
end services in each direction of the PW,
* the need to maintain jitter and wander of the clock of the
egress end service within the limits imposed by the appropriate
normative documents in spite of the packet delay variation
produced by the PSN.
o Specifics of applications using (native and emulated) TDM
circuits,
e.g. voice applications:
* put special emphasis on minimization of one-way delay,
* are relatively tolerant to errors in data.
Other applications might have different specifics.
o Specifics of the customers' expectations regarding end-to-end
behavior of services that contain emulated TDM circuits,
e.g., experience with carrying such services over SONET/SDH
networks increases the need for:
* isolation of problems introduced by the PSN from those
occurring beyond the PSN bounds,
* higher sensitivity to misconnection, etc.
It is our intention that this document will be used in the PWE3
community discussions regarding specific proposals for edge-to-edge-
emulation of TDM circuits.
Riegel, et al. Expires December 17, 2002 [Page 4]
Internet-Draft PWE3 TDM Requirements June 2002
3. Terminology
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 [RFC2119].
The terms defined in [PWE3-FW], Section 1.4 are consistently used,
usually without additional explanations. However:
CE-bound, PSN-bound
These terms are consistently used instead of 'outbound' and
'inbound' when describing traffic directions. These terms have
been adopted in [PWE3-LAYERS].
Interworking function (IWF)
This term is often used for describing the protocol operation with
explicit references to CE-bound or PSN-bound direction of the IWF.
Some terms and acronyms are commonly used in conjunction with the TDM
services. In particular:
Channel-Associated Signaling (CAS)
It is one of several signaling techniques used by the telephony
applications to convey various states of these applications (e.g.,
off-hook and on-hook). CAS uses a certain, circuit-specific
multiframe structure that is imposed on the TDM bit stream and a
predefined association between the relative timeslot (= channel)
number within this stream and position of certain bits within this
multiframe structure. In the case of E1 there are four 500 bit/s
channels for each timeslot used to distinguish and signal
application states (see [G.704] for details).
CAS is also used in conjunction with D4 and ESF formats of T1
using "robbed bits". In case of D4 this results in 2 channels of
333.(3) bit/s, and in case of ESF - 4 such channels.
[## Ed-note##: more details to be included here?]
Common Channel Signaling (CCS)
This is an alternative to the CAS method of signaling used by the
telephony applications. E.g., for SS7 Common Channel Signaling is
described in [Q.700] and references therein.
[## Ed-note##: more to be included here?]
For the TDM network we use the terms "jitter" and "wander" as defined
in [G.823] and [G.824], while for the PSN measures from IETF IPPM
(like packet delay variation - see [IPPM-IPDV]) are used.
Riegel, et al. Expires December 17, 2002 [Page 5]
Internet-Draft PWE3 TDM Requirements June 2002
4. Reference Models
4.1 Generic PWE3 Models
Generic models that have been defined in [PWE3-FW] in Sections
- 3.1 (Network Reference Model),
- 3.2 (Maintenance Reference Model),
- 3.4 (Protocol Stack Reference Model) and
- 3.5 (Logical Protocol Layering Model).
They are fully applicable for the purposes of this document without
any modifications.
All the services considered in this document represent special cases
of the generic circuit-oriented payload type defined in Section
3.5.2.1 of [PWE3-FW].
4.2 Network Synchronization Reference Model
The network synchronization reference model shown in Figure 1 below
is copied, with some modifications, from one of the expired versions
of [PWE3-FW]:
Riegel, et al. Expires December 17, 2002 [Page 6]
Internet-Draft PWE3 TDM Requirements June 2002
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ ^ ^ | | | ^ | ^ ^
| | | |B | | | |<------+------>| | | | | |
| A | +--+ +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
Figure 1: Timing Recovery Reference Diagram
The following notations are used in Figure 1:
CE1, CE2
Customer edge devices terminating TDM circuits to be emulated.
PE1, PE2
Provider edge devices adapting these end services to PW.
S1, S2
Provider core routers
Phy
Physical interface terminating the TDM circuit.
Enc
PSN-bound IWF of the PW
Dec
CE-bound IWF of the PW. It contains a compensation buffer (also
known as the "jitter buffer") of limited size.
Riegel, et al. Expires December 17, 2002 [Page 7]
Internet-Draft PWE3 TDM Requirements June 2002
"==>"
TDM end service circuits
"::>"
PW providing edge-to-edge-emulation for the TDM circuit.
The characters "A" - "L" are denoting various clocks:
"A"
The clock used by CE1 for transmission of the TDM end circuit
towards CE1.
"B"
The clock recovered by PE1 from the incoming TDM end circuit. "A"
and "B" always have the same frequency.
"G", "H"
The same as "A" and "B" respectively for CE2 and PE2 ("G" and "H"
have the same frequency).
"C", "D"
Local oscillators available to PE1 and PE2 respectively.
"E"
Clock used by PE2 to transmit the TDM end service circuit to CE2
(the recovered clock).
"F"
Clock recovered by CE2 from the incoming TDM end service ("E and
"F" have the same frequency).
"I"
If it exists, it is the common network reference clock available
to PE1 and PE2.
"J", "K"
The same as "E" and "F" respectively for PE1 and CE1 ("J" and "K"
have the same frequency).
"L"
If it exists, it is the common reference clock of CE1 and CE2.
Note that different pairs of CE devices may use different common
reference clocks.
One of the objectives of edge-to-edge-emulation of a TDM circuit is
balance between clocks "B" and "E" (i.e., these clocks MUST have the
same frequency). This objective may be achieved by different means
depending on the actual network synchronization scheme deployed.
Riegel, et al. Expires December 17, 2002 [Page 8]
Internet-Draft PWE3 TDM Requirements June 2002
The following groups of the network synchronization deployment
scenarios can be considered:
4.2.1 Synchronous Network scenarios
The common network reference clock "I" is available to all the PE
devices, and local oscillators "C" and "D" are locked to "I":
o One Synchronous Network:
* Clocks "E" and "J" are the same as "D" and "C" respectively.
* Clocks "A" and "G" are the same as "K" and "F" respectively
(i.e., CE1 and CE2 use the so-called loop timing).
o Synchronous Carrier of Carriers:
* Clocks "A" and "G" are locked to the common reference clock "L"
which is not locked to clock "I".
* More than one such clock is used by appropriate pairs of CE
devices connected to the given pair of PE devices PE1 and PE2
(otherwise it could be used by PE1 and PE2 as their common
network reference clock "I").
4.2.2 Asynchronous Carrier of Carriers scenario
The asynchronous scenario is characterized by:
o No common network reference clock "I" is available to PE1 and PE2.
o More than one reference clock is used by CE devices connected to
PE1 and PE2.
Asynchronous Carrier of Carriers scenario clearly represents the
worst case for achieving the goal of balancing clocks "A" and "E".
Note that one of the means available for achieving this goal is the
compensation buffer in the CE-bound IWF, and the balance between
clocks "A" and "E" must be exact over the period required for
replaying out of this buffer.
[##Ed-note##: The section about network synchronization reference
models is for further discussion.]
Riegel, et al. Expires December 17, 2002 [Page 9]
Internet-Draft PWE3 TDM Requirements June 2002
5. Emulated Services
This document defines requirements for the payload and encapsulation
layers for edge-to-edge emulation of TDM services with structured
payload as well as unstructured payload.
Wherever possible, the requirements specified in this document SHOULD
be satisfied by appropriate arrangements of the encapsulation layer
only. The (rare) cases when the requirements apply to both the
encapsulation and payload layers (or even only to the payload layer
only) will be explicitly noted.
Applicability of these requirements to edge-to-edge-emulation of
structured and unstructured SONET/SDH circuits is left for further
study.
The service-specific encapsulation layer for edge-to-edge emulation
comprises the following TDM services over a PSN:
5.1 Structured TDM Circuits
o Transparent N*DS0, 1 <= N <= 31 as described in [G.704].
This circuit can be accompanied by channel-associated or common
channel CE application state signaling.
5.2 Unstructured TDM Circuits
o Unstructured E1 as described in [G.704].
o Unstructured T1 (DS1) as described in [G.704].
o Unstructured E3 as defined in [G.751].
o Unstructured T3 (DS3) as described in [T.107].
Riegel, et al. Expires December 17, 2002 [Page 10]
Internet-Draft PWE3 TDM Requirements June 2002
6. Generic Requirements
6.1 Relevant Common PW Requirements
The combination of encapsulation and payload layers for edge-to-
edge-emulation of TDM circuits considered in this document should
comply with the following common PW requirements defined in [PWE3-
REQ]:
1. Conveyance of Necessary L2/L1 Header Information:
1. For unstructured circuits this functionality MAY be provided
by the payload layer.
2. For structured circuits, the necessary information MUST be
provided by the encapsulation layer.
2. Support of Multiplexing and Demultiplexing if supported by the
native services:
1. Relevant for N*DS0 circuits with or without signaling.
2. For these circuits means that the combination of
encapsulation and payload layers MUST provide for separate
treatment of every DS0 sub-circuit.
3. Intervention or transparent transfer of Control Messages of the
Native Services depending on the particular scenario.
4. Consideration of the PSN Tunnel Header Overhead (see also Section
7.5 below).
5. Detection and handling of PW faults. The list of faults is given
in Section 7.9 below.
6. Clock Recovery (see also Section 7.2 below).
The following requirements listed in [PWE3-REQ] are not applicable to
emulation of TDM services:
o Support of variable length PDUs,
o Segmentation and reassembly,
o Keep-alive,
o RFC 2914 conformance.
Riegel, et al. Expires December 17, 2002 [Page 11]
Internet-Draft PWE3 TDM Requirements June 2002
6.2 Common Circuit Payload Requirements
Structured circuits considered in this document belong to the generic
'Structured Bit-Stream Payload' type defined in [PWE3-LAYERS].
Unstructured circuits considered in this document belong to the
generic Bit-Stream Payload type.
Accordingly, the encapsulation layer MUST provide the common
Sequencing service and SHOULD provide Timing information
(Synchronization services).
Note: The encapsulation layer for the (Structured) Bit-Stream Payload
circuits MAY NOT provide the length service.
6.3 General Design Issues
The combination of payload and encapsulation layers SHOULD comply
with the general design principles of the Internet protocols as
presented in [RFC1958], Section 3.
Riegel, et al. Expires December 17, 2002 [Page 12]
Internet-Draft PWE3 TDM Requirements June 2002
7. Service-Specific Requirements
7.1 Interworking
1. The emulation MUST support network interworking between end
services of the same kind (structured, unstructured) and bit-
rate.
2. The encapsulation layer SHOULD remain unaffected by specific
characteristics of connection between the end services and PE
devices at the two ends of the PW.
7.2 Network Synchronization
1. The encapsulation layer MUST provide synchronization services
that are sufficient for:
1. balancing of clock of ingress and egress end services
regardless of the specific network synchronization scenario,
2. keeping the jitter and wander of the clock of the egress
service within the service-specific limits as defined by the
appropriate normative references.
2. If the same high-quality synchronization source is available to
all the PE devices in the given domain, the encapsulation layer
SHOULD be able to offer additional benefits (e.g., facilitate
better reconstruction of the native service clock).
7.3 Robustness
The robustness of the emulated service does not only depend upon
means applied to the edge-to-edge-emulation but also upon proper
implementation of the procedures of the native TDM service.
7.3.1 Packet loss
Edge-to-edge-emulation of TDM circuits MAY assume very low
probability of packet loss between ingress and egress PE. In
particular, no retransmission mechanisms are required.
In order to minimize effect of occasional loss of a single packet on
the egress service, the encapsulation layer SHOULD:
1. Allow independent interpretation of TDM data in each specific
packet by the egress PE (see [RFC2736]. This requirement MAY be
Riegel, et al. Expires December 17, 2002 [Page 13]
Internet-Draft PWE3 TDM Requirements June 2002
disregarded if the egress PE has to interpret structures that
exceed the path MTU between the ingress and egress PEs.
2. Allow reliable detection of lost packets (See next section). In
particular, it should allow prediction (within reasonable limits)
of the arrival time of the next PW packet and detection of lost
packets that takes such a prediction into account.
3. Minimize possible effect of lost packets on recovery of the
circuit clock by the egress PE depending on the actual network
synchronization scheme deployed.
7.3.2 Out-of-order delivery
The encapsulation layer MUST provide the necessary mechanisms that
guarantee ordered delivery of packets carrying the TDM data over the
PSN. Packets that have arrived out-of-order:
1. MUST be detected,
2. SHOULD [##Ed-Note##: MAY?] be reordered if not judged to be too
late or too early for playout.
Out-of-order packets that cannot be reordered MUST be treated as
lost.
7.4 CE Signaling
Unstructured TDM circuits do not usually require any special
mechanisms for carrying CE signals as these would be carried as part
of the emulated service.
Some CE applications using structured TDM circuits (e.g., telephony)
require specific signaling that conveys changes of state of these
applications relative to the TDM data.
The encapsulation layer SHOULD support signaling of state of CE
applications for the relevant circuits providing for:
1. Ability to support different signaling schemes with minimal
impact on encapsulation of TDM data,
2. Multiplexing of application-specific CE signals and data of the
emulated service in the same PW,
3. Synchronization (within the application-specific tolerance
limits) between CE signals and data at the PW egress,
Riegel, et al. Expires December 17, 2002 [Page 14]
Internet-Draft PWE3 TDM Requirements June 2002
4. Probabilistic recovery against possible occasional loss of
packets in the PSN,
5. Deterministic recovery of the CE application state after PW setup
and network outages.
CE signaling that is used for maintenance purposes (loopback
commands, performance monitoring data retrieval, etc.) SHOULD be
dealt within the scope of the generic PWE3 maintenance protocol.
7.5 PSN bandwidth utilization
1. The encapsulation layer SHOULD allow for an effective trade-off
between the following requirements:
1. Effective PSN bandwidth utilization. Assuming that the size
of encapsulation layer header does not depend on the size of
its payload, increase in the packet payload size results in
increased efficiency.
2. Low edge-to-edge latency. Low end-to-end latency is the
common requirement for Voice applications over TDM services.
Packetization latency is one of the components comprising
edge- to-edge latency and decreases with the packet payload
size.
The compensation buffer used by the CE-bound IWF increases
latency to the emulated circuit. Additional delay introduced by
this buffer SHOULD NOT exceed the packet delay variation observed
in the PSN.
2. The encapsulation layer SHOULD provide for saving the PSN
bandwidth by not sending invalid TDM data across the PSN.
3. The encapsulation layer MAY provide the ability to save the PSN
bandwidth for the structured case by not sending TDM timeslots
that are inactive.
7.6 Packet Delay Variation
In accordance with the PWE3 principles, the PWs do not exert any
control over the underlying PSN. In particular, the encapsulation
layer for edge-to-edge-emulation of TDM circuits does neither affect
one-way delay of packets from ingress to egress PE, nor its
variation.
The encapsulation layer SHOULD provide for ability to compensate for
Riegel, et al. Expires December 17, 2002 [Page 15]
Internet-Draft PWE3 TDM Requirements June 2002
the packet delay variation without affecting jitter and wander of the
egress end service clock.
The encapsulation layer MAY provide for run-time adaptation of delay
introduced by the jitter buffer if the packet delay variation varies
with time. Such an adaptation MAY introduce low level of errors
(within the limits tolerated by the application) but SHOULD NOT
introduce additional wander of the egress end service clock.
7.7 Compatibility with the Existing PSN Infrastructure
The combination of encapsulation and PSN tunnel layers used for edge-
to-edge emulation of TDM circuits SHOULD be compatible with the
existing PSN infrastructures. In particular, compatibility with the
mechanisms of header compression over links where capacity is at a
premium SHOULD be provided.
7.8 Congestion Control
Edge-to-edge emulation of TDM circuits may result in constant bit
rate flows in the PSN. Such flows do not admit any meaningful
congestion control.
7.9 Fault Detection and Handling
The encapsulation layer for edge-to-edge emulation of TDM services
SHOULD, separately or in conjunction with the lower layers of the
PWE3 stack, provide for detection, handling and reporting of the
following defects:
1. Misconnection, or Stray Packets. Importance of this requirement
stems from the customers' expectations based upon powerful means
of misconnection detection in SONET/SDH networks.
2. Loss of packets. Importance of this requirement stems from the
providers' need to distinguish between various causes of the end-
to-end outage of the emulated service.
3. Malformed packets.
4. Loss of synchronization.
7.10 Performance Monitoring
The encapsulation layer for edge-to-edge emulation of TDM services
SHOULD provide for collection of performance monitoring (PM) data
that is compatible with the parameters defined for 'classic', TDM-
Riegel, et al. Expires December 17, 2002 [Page 16]
Internet-Draft PWE3 TDM Requirements June 2002
based carriers of these services. The applicability of [G.826] is
left for further study.
Riegel, et al. Expires December 17, 2002 [Page 17]
Internet-Draft PWE3 TDM Requirements June 2002
8. References
[PWE3-REQ] draft-ietf-pwe3-requirements-02.txt XiPeng Xiao et al,
Requirements for Pseudo Wire Emulation Edge-to- Edge (PWE3), Work in
Progress, May 2002
[PWE3-FW] draft-ietf-pwe3-framework-01.txt Prayson Pate et al,
Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in
progress, June 2002
[PWE3-LAYERS] draft-ietf-pwe3-protocol-layer-00.txt Stewart Bryant et
al., Protocol Layering in PWE3, Work in Progress, May 2002
[IPPM-IPDV] draft-ietf-ippm-ipdv-08.txt C. Demichelis, P. Chimento,
IP Packet Delay Variation Metric for IPPM, Work in progress, November
2001
[RFC1958] B. Carpenter (ed.). Architectural Principles of the
Internet, RFC 1958, IETF, 1996
[RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement
Levels, RFC 2119, IETF, 1997
[RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP
Payload Format Specifications, RFC 2736, IETF, 1999
[G.703] ITU-T Recommendation G.703 (10/98) - Physical/electrical
characteristics of hierarchical digital interfaces
[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s
hierarchical levels
[G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of 34 368 Kbit/s and
the fourth order bit rate of 139 264 Kbit/s and using positive
justification
[G.823] ITU-T Recommendation G.823 (03/00) - The control of jitter
and wander within digital networks which are based on the 2048 kbit/s
hierarchy
[G.824] ITU-T Recommendation G.823 (03/00) - The control of jitter
and wander within digital networks which are based on the 1544 kbit/s
hierarchy
[G.826] ITU-T Recommendation G.826 (02/99) - Error performance
parameters and objectives for international, constant bit rate
Riegel, et al. Expires December 17, 2002 [Page 18]
Internet-Draft PWE3 TDM Requirements June 2002
digital paths at or above the primary rate
[Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT
Signalling System No. 7
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
Authors' Addresses
Maximilian Riegel
Siemens AG
Hofmannstr. 51
Munich 81359
Germany
Phone: +49-89-722-49557
EMail: maximilian.riegel@icn.siemens.de
Alexander (Sasha) Vainshtein
Axerra Networks
24 Raoul Wallenberg St.
Tel Aviv 69719
Israel
Phone: +972-3-7569993
EMail: sasha@axerra.com
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg. C
Tel Aviv 69719
Israel
Phone: +972-3-645-5389
EMail: yaakov_s@rad.co.il
Prayson Pate
Overture Networks, Inc.
P.O. Box 14864
RTP, NC 27709
USA
EMail: prayson.pate@overturenetworks.com
Riegel, et al. Expires December 17, 2002 [Page 19]
Internet-Draft PWE3 TDM Requirements June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Riegel, et al. Expires December 17, 2002 [Page 20]