Internet Draft Ron Cohen
draft-cohen-pwe3-tdmsonetapp-00.txt Lycium Networks
Expires: December 2002 Alexander (Sasha) Vainshtein
Axerra Networks
Tom K. Johnson
Litchfield Communications
David Zelig
Corrigent Systems
Andrew G. Malis
Vivace Networks
Prayson Pate
Overture Networks
Yaron Raz
Atrica
Ray Counterman
Avaya Communications
Tim Frost
Zarlink Semiconductor
June 2002
Applicability statement for edge to edge emulation of Time Division
Multiplexing (TDM) services over Packet Switched Networks (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.
Abstract
This document provides an applicability statement for the transport
of TDM circuits over PSN. The document describes the various
deployment scenarios and the recommended encapsulations and
Expires - December 2002 [Page 1]
TDM emulation applicability statement June 2002
services to be used. In particular, it describes the scenarios
applicable for SONET/SDH derived circuit emulation and scenarios
applicable for native TDM emulation.
Table of Contents
1. Overview......................................................2
2. Fidelity of Emulated TDM services.............................3
2.1 Timing....................................................3
2.2 Service Reliability.......................................4
2.3 End to End delay..........................................4
2.4 Error Rate................................................4
3. Fault Isolation and Performance Monitoring....................5
4. PSN Considerations............................................5
4.1 Path MTU..................................................5
4.2 Bandwidth effectiveness...................................6
4.3 Congestion................................................6
5. Deployment scenarios..........................................6
5.1 Point to Point PDH emulation..............................7
5.2 Multi-Point to Multi-Point SONET/SDH emulation............8
5.3 Multi-point to point PDH to SONET/SDH emulation...........8
6. Security Considerations.......................................9
7. References....................................................9
Author's Addresses..............................................11
1. Overview
This document provides an applicability statement for the transport
of TDM circuits over PSN. The document describes the various
deployment scenarios and the recommended encapsulations and
services to be used. In particular, it describes the scenarios
applicable for SONET/SDH derived circuit emulation and scenarios
applicable for native TDM emulation.
SONET/SDH SPE circuit emulation is described in [CEP-SPE].
Extension of SONET/SDH emulation for SONET VT1.5/2/3/6 and SDH VC-
11/12/2 circuits is described in [CEP-VT]. This draft also
describes bandwidth saving modes for SONET STS-1 and SDH VC-3/4
circuits carrying tributaries or asynchronous E3/T3 signals.
Native TDM circuit emulation for unstructured T1/E1/T3/E3 and
structured N*DS0 circuit emulation is described in [CESoPSN]. The
native encapsulation also supports generic mechanism for carrying
CE application state signaling.
All proposals support the same set of PSN encapsulations,
multiplexing techniques and share a common control word, differing
only in payload. The proposals and the applicability statement all
follow the PWE3 framework [PWE3-FW] and requirements [PWE3-REQ] as
Expires - December 2002 [Page 2]
TDM emulation applicability statement June 2002
well as the protocol layering architectural document [PWE3-LAYERS]
and the design guidelines of the architectual principals of the
Internet document [RFC1958]. In particular, the principle of
minimum intervention that states the payload should, where
possible, be transported as received without modification is
followed.
2. Fidelity of Emulated TDM Services
Emulated TDM services may differ from the alternative to carry them
as native TDM services end to end on the following parameters:
timing, service reliability, end-to-end delay, and bit-error-rate.
Each of these parameters is discussed below.
2.1 Timing
The most predominant differentiator between emulation of TDM
services and emulation of layer-2 services is the need to stand
within the stringent timing and synchronization standards [G.823],
[G.824] and [T1.101]. The requirements on the clock accuracy,
jitter and wander are tighter for the higher rate services.
All protocols allow carrying an emulated signal and the timing of
the emulated signal, independent of the provider network timing
scheme and source.
All protocols do not presume availability of a common synchronous
clock at the ends of a PW (i.e. at the PEs). However, the fidelity
of the recovered TDM timing in this case will be dependent on the
packet-delay variation behavior of the underlying PSN and the
robustness of the timing recovery algorithm used.
In all protocols, it is possible to decouple the timing quality of
the emulated signal from the PSN characteristics by providing a
synchronized clock to both PEs. The required quality of this
synchronization depends on the emulated signal requirements and
application, and is beyond the scope of this document.
Given the rigorous synchronization requirements implied by
emulating core SONET/SDH circuits, it is expected that SONET/SDH
SPE emulation [CES-SPE] will frequently be deployed in situations
where a common timing reference is available at the PW end-points.
It is expected that in point to point PDH circuit emulation and in
PDH to SONET/SDH emulation scenarios common timing reference will
not be available at the PW end points.
Expires - December 2002 [Page 3]
TDM emulation applicability statement June 2002
2.2 Service Reliability
Service Reliability may be impacted by two components: the
robustness of the underlying PSN and whether specific steps have
been taken to protect the emulated service (such as 1+1 protection
switching on the emulated service). The PE's de-jitter buffer and
packet reordering mechanisms reduce the impact of fast PSN
rerouting events on the emulated service. In the case of a failure,
fast protection mechanism in the PSN can guarantee performance
similar to that of the equivalent recovery mechanisms in the native
TDM network.
Occasional loss of a single packet does not result in losing more
information than carried in this packet, since all the protocols
allow independent play out of each packet, as recommended in
[RFC2736].
2.3 End to End Delay
The end-to-end delay will be impacted by the packetization delay,
the transit delay through the PSN and the packet-delay-variation
characteristics of the PSN, as the latter define the minimum de-
jitter buffer length and therefore the incremental delay caused by
the de-jitter buffer operation. The protocol makes no assumption
regarding the delay and delay variation introduced by the PSN.
However, the tighter the bound on transit delay and delay
variation, the shorter the end-to-end delay of the emulated circuit
will be.
The packetization delay within all payload formats is constant for
the duration of the PW and configurable at set up time. The payload
formats differ in the maximal configurable packetization delay.
Longer packetization delay adds to the total delay but increase the
bandwidth efficiency.
Native emulation [CESoPSN] has no restriction on the maximal
packetization delay. SPE based SONET/SDH emulation [CEP-SPE]
restricts the packetization delay to 0.125 ms equivalent to a
single SPE frame. VT based SONET/SDH emulation [CEP-VT] restricts
the packetization delay to 0.5 ms equivalent to 4 T1/E1 frames.
Echo cancellers may be required when one-way end to end delay
exceeds 25 ms [G.131].
2.4 Error Rate
BER will be dependent on the characteristics of the PSN. A BER on a
physical link in the PSN is translated in current PSN links to a
packet drop. Congestion may also lead to packet drop. Packets
arriving too late for the de-jitter buffer depth are effectively
Expires - December 2002 [Page 4]
TDM emulation applicability statement June 2002
dropped. Each such packet drop event will result in a number of
byte errors equivalent to packet length on the emulated signal. The
use of shorter packet lengths can minimize the effect at the cost
of additional total overhead. All payload formats allow packet
length flexibility. New transport technologies enable forwarding
PSN packets for selected services even when there is BER on the
physical links. This will enable in the future better BER
performance of the emulated service.
3. Fault Isolation and Performance Monitoring
The protocol allows collection of PDH and SONET/SDH-like faults and
performance monitoring parameters. Similarity with existing PDH
and SONET/SDH services is increased by the protocol's ability to
carry 'far end error' indications (i.e. RDI). The protocol
performance monitoring capabilities are based on PDH and SONET/SDH
requirements as reflected by the available standards, and adapted
to the nature of the protocol.
The protocol provides the ability to detect lost packets and hence
allows it to distinguish between PSN problems and problems external
to the PSN as causes of outages and/or degradations of the emulated
service. In addition, the protocol supports fast detection of
defects, enabling deployment of rapid fault recovery mechanisms for
the emulated circuit.
4. PSN Considerations
Limitation on Path MTU, bandwidth considerations and congestion
control implications are discussed below.
4.1 Path MTU
Some assumptions on path MTU are made. The assumptions are as
follows:
Path MTU between a pair of PEs SHOULD allow carrying CEP payload of
783 bytes for SONET/SDH circuit emulation defined in [CEP-SPE] and
for fractional STS-1/VC-3/VC-4 defined in [CEP-VT].
Path MTU between a pair of PEs MUST allow carrying payload of 537
bytes (for unstructured E3) and 699 bytes (for unstructured T3)
[CESoPSN].
While these requirements exceed the minimal IP path MTU defined in
[RFC1122], they are easily met in most modern core packet-switching
networks.
Expires - December 2002 [Page 5]
TDM emulation applicability statement June 2002
4.2 Bandwidth Effectiveness
The protocol allows for bandwidth conservation in the PSN by
carrying only AIS and/or unequipped/Idle indications instead of
empty payloads.
Payload compression of SONET/SDH STS-1/VC-3/VC-4 circuits carrying
tributaries and SONET/SDH STS-1/VC-3 carrying asynchronous DS-3/E3
PDH signals is defined in [CEP-VT]. The first method provides the
ability to carry any number of tributaries 1-28 within a SONET STS-
1 emulated circuit and 1-84 tributaries for an SDH VC-4 emulated
circuit omitting unequipped or unswitched tributaries. The second
method drops the fixed columns within the STS-1/VC-3 asynchronous
DS-3/E3 emulated circuit providing up to 28% bandwidth saving.
[CESoPSN] N*DS0 structured service provides bandwidth efficient
encapsulation for Fractional T1/E1 applications, carrying only the
relevant DS0 across the PSN.
Longer packetization delay increases the bandwidth effectiveness
but adds to the total end to end delay and to the cost of packet
loss (BER). The tradeoffs and limitations on the maximal
packetization delay are discussed in a previous section.
In addition to the encapsulation overhead, each protocol adds PSN
specific overhead and control word and RTP header. In some
scenarios, and depending on the protocol, the RTP header may be
compressed. Specifically, in [CEP-VT]and [CEP-SPE] the RTP overhead
may be compressed independent of the timing mode used.
4.3 Congestion
Being a constant bit rate (CBR) service, the protocol cannot
provide TCP-friendly behavior under network congestion. It will
operate best in environments where the Diff-Serv EF PHB with
allocated bandwidth is available end-to-end between the PW
endpoints and the EF bandwidth is sized to meet the requirements of
the emulated TDM circuits, or over a well engineered path as
available through the relevant signaling protocols like RSVP-TE and
CR-LDP for MPLS PSNs. Using these methods will prevent contention
between the TDM Emulation protocol and TCP traffic. Unusable
service characteristics from the packet switched network may be
used to trigger circuit/PW teardown or switch-over.
5. Deployment Scenarios
This section describes the various TDM emulation deployment
scenarios and recommends the best encapsulation type for each. In
Expires - December 2002 [Page 6]
TDM emulation applicability statement June 2002
deployment scenarios where more then one option exists, the
considerations for selecting one of the recommended options are
indicated. The considerations include (not in order of importance)
simplicity, flexibility, bandwidth utilization, operation and
maintenance features, and the services expected by deployment of
(non-emulated) circuits in similar environments.
5.1 Point to Point PDH Emulation
Point to Point PDH emulation deployment scenario refers to
scenarios where a structured or unstructured PDH circuit is
emulated across the PSN. The lists of services are:
1. Structured services:
a. N*DS0, 1 <= N <= 31 as described in [G.704].
2. Unstructured services
a. Unstructured E1 as described in [G.704][G.703]
b. Unstructured T1 (DS1) as described in [T.157a]
c. Unstructured E3 as defined in [G.751]
d. Unstructured T3 (DS3) as described in [T.157a]
The native payload format defined in [CESoPSN] provides a simple
and efficient encapsulation for emulation of these point to point
PDH services. The payload of each packet includes constant number
TDM data bytes. Apart of aligning T1s 193 bits into a 25 byte
payload, no other overhead is added. Application state signaling
(e.g., CAS) can be supported using the appropriate generic
mechanism.
Structured N*DS0 emulated service includes fractional E1/T1
applications that save bandwidth at the PSN by transferring only
"used" timeslots of an E1/T1 circuit, yet allow the CEs to use
traditional circuit state indications (AIS/RDI).
The payload formats defined in [CEP-VT] can be used to emulate
structured PDH services using the SONET/SDH byte-synchronous
mapping into SONET/SDH encapsulation and unstructured services
using the SONET/SDH bit-asynchronous mappings [GR.253][G.707].
These payload formats add SONET/SDH overhead bytes, and therefore
are less bandwidth efficient. This encapsulation effectively
creates SONET/SDH circuits between the PEs to carry the PDH
signals. The additional overhead may be justified in scenarios
where multiple PDH circuits are carried from one PE to the other,
or when the service expectations include SONET/SDH like operation,
administration, maintenance and provisioning (OAM&P) capabilities.
Expires - December 2002 [Page 7]
TDM emulation applicability statement June 2002
5.2 Multi-Point to Multi-Point SONET/SDH Emulation
[CEP-SPE] defines SONET/SDH circuit emulation for SONET STS-1/SDH
VC-3 SPEs as well as for the higher concatenated STS-Nc SPE (N = 3,
12, 48, or 192)/SDH VC-4, VC-4-4c, VC-4-16c, or VC-4-64c SPEs.
Because the protocol terminates the SONET/SDH section and line
before emulating the individual SPEs, the protocol allows the PSN
to operate as a distributed SONET/SDH STS level cross-connect.
[CEP-VT] adds circuit emulation for SONET VT1.5/2/3/6 and SDH VC-
11/12/2 circuits. Together the provide emulation for the complete
SONET/SDH circuit hierarchy.
Because the protocol can also terminate the SONET/SDH path [CEP-VT]
before emulating the individual SONET VTs or SDH VC-11/12/2, the
protocol allows the PSN to operate as a distributed SONET/SDH VT
level cross-connect.
[CEP-VT] defines fractional STS-1/VC-3/VC-4 payload formats
removing all unequipped or unswitched tributaries. Alternatively,
only the relevant tributaries can be switched using the SONET
VT1.5/2/3/6 or SDH VC-11/12/2 payload format.
The fractional STS-1/VC-3/VC-4 encapsulation is the only technique
that allows carriage of virtually concatenated tributaries. It
ensures that the delay variation introduced by the emulation
process would be the same for all tributaries within the
concatenated service, enabling easier implementation of the virtual
concatenation termination. An example of use of virtual
concatenation for delivering PPP streams is defined in [RFC3255].
5.3 Multi-point to point PDH to SONET/SDH Emulation
The access and metro networks can benefit from the deployment of
circuit emulation technology, aggregating multiple PDH circuits
into a SONET/SDH uplink. This deployment is fostered by the
development of new layer 2 packet technologies adapted specifically
for the access and metro network requirements. Multiple provider
edge (PE) access devices provide PDH links (T1/E1/T3/E3) to their
CEs while a PE closer to the central office aggregates the circuits
to a SONET/SDH OC-3/OC-12 trunk.
Two approaches can be taken. The first approach is to extend the
SONET/SDH trunk across the PSN [CEP-VT] towards the PDH PEs. The
second approach is using the native TDM emulation [CESoPSN] to
extend the PDH links over the PSN and map the PDH signals into the
SONET/SDH trunk at the SONET/SDH PE.
Expires - December 2002 [Page 8]
TDM emulation applicability statement June 2002
Using the [CEP-VT] payload format the relevant circuits are
extracted from the SONET/SDH trunk and sent unmodified across the
PSN to the access PEs. The SONET/SDH overhead bytes are used to
extend the OAM&P functionality up to the access PEs. This extension
of OAM&P includes the ability to monitor errors across the entire
SONET/SDH path, including bit parity, remote error indications, end
to end path trace functionality and protection functionality. The
SONET/SDH emulation allows the required flexibility of the number
of circuits distributed over the PSN to each access device. A SONET
VT1.5 circuit delivering a T1 circuit across the PSN can be
extended into a fractional STS-1 circuit carrying 5 VT1.5 and
finally extended to a complete STS-1 carrying 28 VT1.5 circuits,
according to the increasing demand for emulated circuit ports
within the same access PE.
Using the native payload format [CESoPSN], the PDH circuits can be
extended across the PSN and mapped to the SONET/SDH trunk at the
SONET/SDH PE. The flexibility in the maximal payload size and the
N*DS0 payload format can be used to optimize bandwidth efficiency.
6. Security Considerations
TDM circuit emulation does not introduce additional security
considerations beyond those discussed in section 9 of [PWE3-
LAYERS].
7. References
[CEP-SPE] Malis et al, "SONET/SDH Circuit Emulation over Packet
(CEP)", draft-malis-pwe3-sonet-03.txt, work in progress, June 2002.
[CESoPSN] Vainshtein et al, "TDM Circuit Emulation Service over
Packet Switched Network", draft-vainshtein-cesopsn-03.txt, work in
progress, June 2002.
[CEP-VT] Pate et al, "TDM Service Specification for Pseudo-Wire
Emulation Edge-to-Edge", draft-pate-pwe3-tdm-04.txt, work in
progress, June 2001.
[PWE3-REQ] XiPeng Xiao et al, "Requirements for Pseudo Wire
Emulation
Edge-to-Edge (PWE3)", Work in Progress, July-2001, draft-ietf-pwe3-
requirements-01.txt
[PWE3-FW] Prayson Pate et al, "Framework for Pseudo Wire Emulation
Edge-to-Edge (PWE3)", Work in progress, February 2002, draft-ietf-
pwe3-framework-00.txt
Expires - December 2002 [Page 9]
TDM emulation applicability statement June 2002
[PWE3-LAYERS], Stewart Bryant et al., "Protocol Layering in PWE3",
Work
in Progress, February 2002, draft-bryant-pwe3-protocol-layer-01.txt
[RFC1958] B. Carpenter, "Architectual Principles of the Interenet",
RFC 1958, IETF, June 1996.
[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.824 (03/00) û The control of jitter
and wander within digital networks which are based on the 1544
kbit/s hierarchy
[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.703] ITU-T Recommendation G.703 (91) - Physical Electrical
Characteristics of Hierarchical Digital Interface
[G.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface
for Synchronous Digital Hierarchy (SDH)
[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.802] ITU-T Recommendation G.802 (11/88) - Interworking between
networks based on different digital hierarchies and speech encoding
laws
[G.826] ITU-T Recommendation G.826 (02/99) - Error performance
parameters and objectives for international, constant bit rate
digital paths at or above the primary rate
[GR.253] Telcordia Technologies, "Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria", GR-253-CORE,
Issue 3, September 2000.
[GR.1244] Telcordia Technologies, "Clocks for the Synchronized
Network: Common Generic Criteria", GR-1244-CORE, Issue 2, December
2000.
[T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface
Rates and Format Specifications (SONET}
Expires - December 2002 [Page 10]
TDM emulation applicability statement June 2002
[T1.101] ANSI T1.101-1999. Synchronization interface standards.
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
[RFC3255] N. Jones, C. Murton, "Extending Point-to-Point Protocol
(PPP) over Synchronous Optical NETwork/Synchronous Digital
Hierarchy (SONET/SDH) with virtual concatenation, high order and
low order payloads", RFC 3255, IETF, April 2002
[RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP
Payload Format Specifications, RFC 2736, IETF, 1999
[RFC1122] R. Braden (ed.), Requirements for Internet Hosts --
Communication Layers, RFC 1122, IETF, 1989
[G.131] ITU-T Recommendation G.131 (08/96) - Control of talker
echo.
Author's Addresses
Ron Cohen
Lycium Networks
9 Hamanofim St. Phone: +972-9-971-7794
Herzelia 46733, Israel Email: ronc@lyciumnetworks.com
Alexander (Sasha) Vainshtein
Axerra Networks
24 Raoul Wallenberg St. Phone: +972-3-7569993
Tel Aviv 69719, Israel Email: sasha@axerra.com
Tom K. Johnson
Litchfield Communications
Princeton Building East
27 Princeton Road, Watertown Phone: +1-203-591-7063
CT, 06795, USA. Email:tom_johnson@litchfieldcomm.com
David Zelig
Corrigent Systems LTD.
126, Yigal Alon st. Phone: +972-3-6945273
Tel Aviv, Israel Email: davidz@corrigent.com
Andrew G. Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com
Prayson Pate
Overture Networks
P.O.Box 14864 Phone: +1-919-5582200
RTP, NC, USA 27709 Email: prayson.pate@overturenetworks.com
Expires - December 2002 [Page 11]
TDM emulation applicability statement June 2002
Yaron Raz
Atrica
5 Shenkar St. Phone: +972-9-9707227
Herzelia 46733, Israel Email: yaron_raz@atrica.com
Ray Counterman
Avaya Communications
300 Baker Avenue, Suite 100
Concord, MA 01742, USA Email: rcounterman@avaya.com
Tim Frost
Zarlink Semiconductor
Tamerton Road, Roborough Phone: +44-1752-693840
Plymouth, PL6 7BQ, U.K. Email: tim.frost@zarlink.com
Acknowledgement
The authors wish to thank Aharon Segev from AxonLink for his review
of the draft.
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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
Expires - December 2002 [Page 12]
TDM emulation applicability statement June 2002
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires - December 2002 [Page 13]