Network Working Group Alexander ("Sasha") Vainshtein
Israel Sasson
Akiva Sadovski
Internet Draft Axerra Networks
Expiration Date: Eduard Metz
May
August 2002 KPNQwest
November 2001
Tim Frost
Zarlink Semiconductor
February 2002
TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)
draft-vainshtein-cesopsn-01.txt
draft-vainshtein-cesopsn-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC 2026.
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.
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 describes a method for encapsulating TDM digital
signals defined in the plesiochronous digital hierarchy (PDH)
as a pseudo-wire (PW) over various packet-switched networks (PSN).
In this regard this document complements similar work for SONET/SDH
circuits.
Proposed PW encapsulation uses RTP for clock recovery and supports
signaling between Provider Edge (PE) devices.
Encapsulation proposed in this document may be extended to low-rate
SONET/SDH traffic as well.
TABLE OF CONTENTS
1. Introduction 3
2. Summary of Changes from the -00 -01 Revision 3
TDM Circuit Emulation Service over PSN August 2002
3. Terminology and Reference Models 4
3.1. Terminology 4
3.2. Reference Models 5
3.2.1. Generic Models 5
3.2.2. Service Examples 5
TDM Circuit Emulation Service over PSN November 2001
3.2.3. Layering Synchronization Considerations and Protocol Stack Layering Model Deployment Scenarios 5
3.2.4. Timing Reference Models
3.2.3. Service Examples 6
4. Scope and Requirements 7
4.1. TDM Emulated Services 7
4.1.1. Structured vs. Unstructured TDM Circuits 7
4.1.2. PDH Circuits 7
4.1.3.
4.1.2. SONET/SDH Circuits 7
4.2. Relevant Types of PSN Scope 7
4.3. Interworking and Signaling 8 Generic Requirements 7
4.3.1. CE Signaling 8 Relevant Common PW Requirements 7
4.3.2. PE/PW Signaling Common Circuit Payload Requirements 8
4.3.3. The Principle of Minimal Intervention 8
4.4. PW OAM 9 Service-Specific Requirements 8
4.4.1. Fault detection and Handling 9 Interworking 8
4.4.2. PW Maintenance 9
5. Specifics of Pseudo-Wire Emulation for PDH Circuits Network Synchronization Schemes 8
4.4.3. CE Signaling 9
5.1. Native Frame Size
4.4.4. Latency and Encapsulation Effectiveness 9
5.2. Synchronization
4.4.5. Fault Detection and Handling 10
5.3. Conclusion
4.4.6. Performance Monitoring 10
6.
4.4.7. Bandwidth Saving 10
4.4.8. Adaptation of the Jitter Buffer 10
5. CESoPSN Encapsulation 10
6.1.
5.1. Generic CESoPSN Format 10
6.2.
5.2. CESoPSN Header 11
6.2.1.
5.2.1. Usage of RTP Header 11
6.2.2.
5.2.2. Usage and Structure of the Control Word 12
6.3.
5.3. Payload Data Format 13
6.3.1. Fractional E1/T1 Circuits 13
6.3.2. Unstructured TDM
5.3.1. Transparent N*DS0 Circuits 14
6.3.3. "T1-in-E1" Mode for
5.3.2. N*DS0 circuits with CAS 15
5.3.3. Unstructured T1 TDM Circuits 14
7. 16
6. CESoPSN Operation 15
7.1. New 17
6.1. Payload Parameters 18
6.1.1. PW Types 15
7.2. Type 18
6.1.2. Circuit Bit Rate 16
7.3. 18
6.2. Encapsulation Layer Parameters 19
6.2.1. Usage of Control Word 16
7.4. Common L1 (Circuit)PW Layer Parameters 16
7.4.1. 19
6.2.2. RTP Payload Type 19
6.2.3. Payload Bytes 16
7.4.2. 19
6.2.4. Timestamp Resolution 20
6.2.5. Synchronization Clock Rate 17
7.5. Source ID 20
6.2.6. Timestamp Generation Mode 20
6.3. End Service Inactivity Behavior 17
7.6. 20
6.4. Description of the IWF operation 17
7.6.1. Outbound 20
6.4.1. PSN-bound Direction 17
7.6.2. Inbound 20
6.4.2. CE-bound Direction - Normal Operation 17
7.6.3. Inbound-to-Outbound 21
6.4.3. IWF Loopback 18
7.7. 22
6.5. CESoPSN Defects 18
7.7.1. Precedence of Faults 18
7.7.2. 22
6.5.1. Misconnection 19
7.7.3. 22
6.5.2. Re-Ordering and Loss of Packets and Re-Ordering 19
7.7.4. Payload Mistype 20
7.7.5. 23
6.5.3. Malformed Packets 23
TDM Circuit Emulation Service over PSN August 2002
6.5.4. Loss of Synchronization 20
7.8. 24
6.6. Performance Monitoring 24
6.6.1. Errored Data Blocks 24
6.6.2. Errored, Severely Errored and Unavailable Seconds 25
6.7. QoS Issues 21
8. 25
7. RTP Payload Format Considerations 21
8.1. 25
7.1. Resilience to moderate loss of individual packets 21
8.2. 25
7.2. Ability to interpret every single packet 21
8.3. 25
7.3. Non-usage of the RTP Header Extensions 21
8.4. Treatment of the decoder internal data-driven state 22
8.5. 25
7.4. Compression of RTP headers 22
9. 25
8. Congestion Control (RFC 2914) Conformance 22
TDM Circuit Emulation Service over PSN November 2001
10. 26
9. FFS Issues 22
11. 26
10. Security Considerations 23
12. 26
11. Applicability Statement 23
13. 26
12. IANA Considerations 24
14. 28
13. Intellectual Property Considerations 24 28
ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 28 32
ANNEX B. EMULATION OF SONET/SDH CIRCUITS 30
ANNEX C. A COMMON PW SETUP AND TEARDOWN MECHANISM 32
ANNEX D. COMPARISON of DIFFERENT APPROACHES 35 34
1. Introduction
This document describes a method requirements for encapsulating edge-to-edge emulation of
time division multiplexed (TDM) digital signals defined in
Plesiochronous Digital Hierarchy (PDH), see [G.703], [G.704],
[T.107] [T1.103] and [T1.107a], for
emulation over a packet-switched network (PSN). In this regard this
specification complements [MALIS] [T1.107a] and [PWE3-SONET]. a corresponding encapsulation
technique.
To support TDM traffic, which includes voice, data, and private
leased line service, the network must emulate the circuit
characteristics of PDH. a TDM network. A new circuit emulation header
and RTP-based mechanisms for carrying clock over PSN are used to
encapsulate TDM signals and provide the Circuit Emulation Service
over PSN (CESoPSN).
Primary application of the technique described in this document is
emulation of PDH circuits in situations when native PDH traffic is
generated by CE devices and does not depend upon the way this
traffic reaches PE devices (see reference model devices. However, its use may be extended to
carrying SDH traffic as "unstructured TDM", thus providing an
alternative to the approach defined in [MALIS].
The CESoPSN solution presented in this document fits the framework
for PWE3 PW services as described in [PWE3-FW] and satisfies the general
requirements put forward in [PWE3-REQ].
2. Summary of Changes from the -00 -01 Revision
Note: This section will be removed from the final document.
1. Text related to compression A section on generic and service-specific requirements for
edge-to-edge emulation of RTP headers compression TDM circuits has been added
2. Compliance Fractional E1/T1 has been consistently replaced with requirements for congestion handling is
described in some detail N*DS0
TDM Circuit Emulation Service over PSN August 2002
3. Explanation Support of differences between PDH and SDH circuits channel-associated CE signaling (CAS) for N*DS0
services based upon the techniques defined in [RFC2833] has
been
updated
4. Considerations regarding two major applications - "One Network"
and "Carriers' Carrier" - have been added
5.
4. The structure of the control word has been simplified and minor
bugs fixed
6. aligned with the
[MARTINI-ENCAP]
5. References have been updated in accordance with the latest
developments
TDM Circuit Emulation Service over PSN November 2001
6. RTP Payload Types have been decoupled from PW types. Dynamic
allocation of PT values will be used instead
7. Comparison Most of different approaches for carrying PDH traffic over
PSN the text that should logically belong to more generic
PWE3 documents and/or tutorials has been added as Annex D (to be removed from the final
version
8. In-band CESoPSN loopback commands have been removed
9. G.826-compatible PM parameters for CESoPSN have been defined
10. A brief description of the document). adaptive jitter buffer behavior has
been added.
3. Terminology and Reference Models
3.1. 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 following terms have been originally defined in [PWE3-FW], Section 2 1.4 are consistently used,
usually without additional explanations. However:
o The terms 'CE-bound' and 'PSN-bound' are consistently used
instead of
[PWE3-FW]. 'outbound' and 'inbound' when describing traffic
directions
o The text below has been slightly modified limiting term "Interworking function" (IWF) is often used for
describing the
scope protocol operation with explicit references to
CE-bound or PSN-bound direction of the services considered IWF.
Some terms and acronyms are commonly used in this document:
Packet Switched A Packet Switched Network (PSN) is a network
Network using IP, MPLS or L2TP as conjunction with the unit of
switching.
Pseudo Wire Emulation Pseudo Wire Emulation Edge to Edge (PWE3)
TDM services. In particular:
o Alarm Indication Signal (AIS) is a
Edge to Edge mechanism that emulates common term denoting a
special bit pattern in the essential
attributes TDM bit stream that indicates
presence of a service (such as a T1 leased
line) over a PSN.
Customer Edge A Customer Edge (CE) an upstream circuit outage
o Channel-Associated Signaling (CAS) is a device where one end of an emulated service originates and
terminates. The CE is not aware that it is
using an emulated service rather than a "real"
service.
Provider Edge A Provider Edge (PE) is a device that provides
PWE3 to a CE.
Pseudo Wire A Pseudo Wire (PW) is a connection between two
PEs carried over a PSN. The PE provides the
adaptation between the CE and the PW.
PW End Service A Pseudo Wire End Service (PWES) is several signaling
techniques used by the
interface between a PE telephony applications to convey
various states of these applications (e.g., off-hook and ob-
hook). CAS uses a CE. This can be
o A physical interface like T1
o A virtual interface like:
o T1 carried in DS3 (using M13 or M23
multiplexing certain, circuit-specific multiframe
structure - see
[T1.103])
o T1 carried in VT1.5/VC12 in a
SONET/SDH stream
Pseudo Wire PDU A Pseudo Wire PDU that is a PDU sent imposed on the PW that
contains all of TDM bit stream and a
predefined association between the data relative timeslot (=
channel) number within this stream and control
information necessary position of certain
bits within this multiframe structure. Up to provide the desired
service.
PSN Tunnel A PSN Tunnel is a tunnel inside which multiple
PWs 16 application
states can be nested so that they are transparent
to core network devices. distinguished and signaled (see [G.704] for
details).
TDM Circuit Emulation Service over PSN November 2001 August 2002
3.2. Reference Models
3.2.1. Generic Models
Generic Network and Signaling Reference Models for PWE3 models that have been defined in Sections 3.2.1 3.1 (Network
Reference Model), 3.2 (Maintenance Reference Model), 3.4 (Protocol
Stack Reference Model) and 3.2.2 3.5(Logical Protocol Layering Model) of
[PWE3-FW] and 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].
3.2.2. Synchronization Considerations and Deployment Scenarios
Two basic issues must taken into account regarding possible
synchronization techniques for emulation of circuit-oriented
services:
o Can all the PE devices of the given pseudo-wire domain (PWD)
be synchronized? Or, in more precise terms, is the same high-
quality synchronization source available to all the PE devices
in the given PWD?
o Is the CE device synchronized to the same source as its
'local' PE?
The answer to the first question depends upon design of the specific
PSN. E.g. PE devices in a PSN based entirely on POS links can be
easily synchronized while PE devices of a PSN based on Gigabit
Ethernet links (or on a mix of Gigabit Ethernet and POS) would as
often as not remain unsynchronized.
The answer to the second question depends on specifics of the
customers served by the PSN operator. In particular, if the CE
devices are just nodes in the customers' TDM networks with their own
synchronization schemes, they would probably continue to use these
schemes even if the PSN is fully synchronized.
Combinations of answers to these basic questions provide at least
three viable deployment scenarios:
1. "One Synchronous Network" Scenario, i.e.:
a. The same high-precision synchronization source is
available in all the PE devices of the given PSN
b. This synchronization source is also used by all the CE
devices terminating TDM end services of PWs crossing the
PSN
c. The PW mechanisms must provide compensation only for the
packets inter-arrival jitter introduced by the PSN
2. "Synchronous Carriers' Carrier" Scenario, i.e.:
a. The same high-precision synchronization source is
available in all the PE devices of the given PSN
b. Each Emulated circuit connects two CEs that are either
loop-timed to the corresponding PE or synchronized to
their own synchronization source
TDM Circuit Emulation Service over PSN August 2002
c. The PW must carry the difference between the PSN clock and
the CE clock over the PSN as well as compensate the
packets' inter-arrival jitter introduced by the PSN
3. "Asynchronous Carriers' Carrier" Scenario, i.e.:
a. Each PE uses its own synchronization source. The quality
of this source is selected in accordance with requirements
of the emulated services (e.g., a Stratum 4 clock is
sufficient for E1 and T1 services)
b. Each emulated circuit connects two CEs that are either
loop-timed to the corresponding PE or synchronized to
their own synchronization source
c. Every direction of the PW must carry the original line
clock of its end service across the PSN as well as
compensate for the packets' inter-arrival jitter
introduced by the PSN.
3.2.3. Service Examples
Fig.1 below presents several examples of a T1 Emulated Service. These examples
have been adapted from ones presented in Section 4.1 of [PWE3-FW].
___ ___
_/
_/_ \ / \ / \ /\
+------+ Physical /+-+ \__/ \ _ Hub Site
|Site A| T1 / |P| +---+ \ (CE-3)
|T1 #1=|====================|E|=| R | +---+ +-+ \ OC12+------+
|(CE-1)| \ |1| | |===| | | |---------| |
+------+ / +-+ +---+ | | | | ========|=T1 #1|
/ | R |=|P| | |
+------+ T1 +---+ DS3 / +-+ +---+ | | |E| ========|=T1 #2|
|Site B| | |-----------|P| | R |===| | |3|---------| |
|T1 #2=|====|M23|===========|E|=| #2=|====|M13|===========|E|=| | +---+ +-+ / +------+
|(CE-2)| | |-----------|2| +---+ /
+------+ +---+ \ +-+ /
\ ___ ___ /
\_/ \____/ \___/
Figure 1: T1 Emulation Example Diagram
In this diagram, T1 end services circuits are perceived by attached to the PE devices in three
different ways:
o As a physical T1 line (between CE-1 and PE-1)
o As a virtual T1 signal multiplexed in a DS3 using one of
possible multiplexing formats (between CE-2 and PE-2, see
[T1.103] for details). M23 is a PDH multiplexor implementing
muxing of physical T1 lines into DS3 signal
o As a virtual T1 signal mapped into a VT1.5 an appropriate SONET
virtual tributary
which, in its term is tributary, the latter being multiplexed in OC-12
(between CE-3 and PE-3 - see [T1.105] or [G.707] for details).
The CESoPSN PW discussed in this document should be able to cope with
all these use cases in a uniform way.
3.2.3. Layering and Protocol Stack Layering Model
This document uses logical protocol layering model described in
[BRYANT-LAYERS], Section 1:
Payload Layer Data exchanged between CE
TDM Circuit Emulation Service over PSN November 2001
devices
Payload Protocol used to allow The header
Convergence Layer effective regeneration of the associated with
carried service at egress these two layers
Common PW Layer Protocol that provides common (without the PW
services required by PWs demuxing field)
carrying L1 circuits will be later
including demuxing, referred to as
sequencing and "the CESoPSN
synchronization header"
Carrier Protocol used to augment the Empty for PWs
Convergence Layer Carrier Layer with services considered in
like packet length and this document
fragmentation
Carrier Layer Protocol used to deliver
packets from the ingress PE
device to egress one
Note: This model represents an alternative to the generic Protocol
Stack Reference Model described in Section 3.2.3 of [PWE3-FW].
3.2.4. Timing Reference Models
Section 4.4.1 of [PWE3-FW] describes in detail a timing reference
model for a single L1 PW.
However, it seems reasonable to expect more than one such PW to be
supported by a single PE. This raises the question of possible
interaction between clocks for multiple PWs.
Timing-wise, two polar scenarios can be considered:
"One Network" Scenario
In this scenario the same high-precision external clock is available
in all the PE devices of the given PSN and, in addition, is used as
the synchronization source by all the CE devices terminating L1 PWs
crossing the PSN. As a consequence, the L1 PW clock recovery schemes
must provide compensation only for the packets inter-arrival jitter
introduced by the PSN.
"Carriers' Carrier" Scenario
L1 PWs connect (otherwise, isolated) components of TDM networks, and
each of these networks uses each its own synchronization source(s)
and its own timing distribution scheme. Precision of these sources is
selected in accordance with the native requirements of the TDM
network, so that sources used by different networks may differ
accordingly. Each network relies on L1 PWs to be part of its timing
distribution scheme in addition to carrying L1 data. This means that
the L1 PW clock recovery schemes must provide for:
TDM Circuit Emulation Service over PSN November 2001
o Compensation of the packets inter-arrival jitter introduced
by the PSN
o Compensation of the native jitter of the incoming line clock
o Recovery, within the standards-defined precision limits, of
the native wander of the incoming line clock.
Real-life deployment may present a mix of these two use cases, and
CESoPSN should be able with such a mix. August 2002
4. Scope and Requirements
4.1. TDM Emulated Services
4.1.1. Structured vs. Unstructured TDM Circuits
The difference between structured and unstructured TDM circuits is
discussed in some detail in [PWE3-FW], Section 4.2.2.
CESoPSN may be used for emulating both structured and unstructured
PDH circuits and unstructured SONET/SDH Circuits.
4.1.2. PDH Circuits
Encapsulation format described in this
This specification is designed describes service-specific encapsulation layer
for
carrying edge-to-edge emulation of the following PDH TDM services over a PSN:
o Fractional E1/T1 (also referred to
1. Structured services:
a. Transparent N*DS0, 1 <= N <= 31 as N*DS0). This is the only
structured PDH circuit considered described in this document. Up to 31
timeslots may be transferred over a structured E1, and up to 24
timeslots - over a structured T1
o [G.704].
b. N*DS0 with channel-associated signaling (CAS) as described
in [G.704], 1<= N <= 30
2. Unstructured services
a. Unstructured E1 as described in [G.704]
o
b. Unstructured T1 (DS1) as described in [T.157a]
o
c. Unstructured E3 as defined in [G.751]
o
d. Unstructured T3 (DS3) as described in [T.157a]
Note: Fractional E1/T1 circuits with CAS signaling over CESoPSN are
left for further study.
4.1.3.
4.1.2. SONET/SDH Circuits
Encapsulation format layer described in this specification may MAY be, with
some modifications, also applied to used for emulation of unstructured "low-rate" (STS-
1/STM-0, "low-
rate" (STS-1/STM-0, STS-3c/STM-1) SONET/SDH circuits. Details are
discussed in Annex B.
4.2. Relevant Types Scope
This specification defines only the encapsulation layer for edge-to-
edge emulation of PSN TDM services mentioned in Section 4.1.
In accordance with [PWE3-FW] the PW encapsulation logical protocol layering architecture for a
PWE3, the encapsulation layer MUST NOT be dependent upon specific
service
instantiations of:
1. The PSN layer (i.e. IPv4, IPv6 or MPLS). In order to satisfy
this requirement, encapsulation should be equally applicable used on packets of
fixed size to avoid possible need in the PSN-specific optional
length service
2. Multiplexing layer. In order to satisfy this requirement and,
at least the same time, to allow detection of 'stray packets' the
encapsulation header SHOULD provide some means for identifying
the packets as belonging to the PW.
4.3. Generic Requirements
Note: This and the following types section should be split into a separate
requirements document.
4.3.1. Relevant Common PW Requirements
The encapsulation layer for TDM services considered in this document
should comply with the following common PW requirements defined in
[PWE3-REQ]:
1. Conveyance of PSN networks:
o IP
o L2TP
o MPLS. Necessary L2/L1 Header Information - relevant
only for TDM structured services
TDM Circuit Emulation Service over PSN November 2001
The layering model August 2002
2. Support of Multiplexing and Demultiplexing if supported by
the native services - relevant for PW discussed in Section .3.2.3 above allows N*DS0 circuits with or
without CAS
3. Handling Control Messages of the
following interpretation Native Services - relevant
only for structured TDM services
4. Consideration of this requirement:
o IP and MPLS are considered as two different carrier layers
o L2TP, L2TPv3, GRE, the PSN Tunnel Header Overhead (see also
Section 4.4.4 below)
5. Detection and UDP are considered as different carrier
convergence layers over IP
o MPLS can be handling of PW faults (see also considered as a convergence layer over both IP
(in Section 4.4.5
below). In particular, ability to detect loss of packets
SHOULD be supported in order to allow differentiation
between outages of the MPLS-in-IP model) emulated service resulting from PSN
problems and MPLS carrier layers.
This these resulting from problems beyond the PSN
6. Clock Recovery (see also Section 4.4.2 below).
4.3.2. Common Circuit Payload Requirements
All the services considered in this document is limited belong to describing the CESoPSN encapsulation,
e.g., generic
'Circuit Payload' type defined in [PWE3-FW], Section 3.5.2.1.1.
Accordingly, the data plane of encapsulation layer MUST provide the payload convergence common
Sequencing service and SHOULD provide timing information.
The encapsulation layer used for
carrying circuits listed in Section .4.1 above. This encapsulation can
be carried over multiple combinations the Circuit Payload services does not
necessarily have to provide the length service.
4.3.3. The Principle of Carrier layers and PW
demuxing techniques. Some details are described in Annex A.
Note: Some preliminary considerations on Minimal Intervention
The encapsulation layer SHOULD comply with the control plane for
CESoPSN are principle of minimal
intervention as described in [PWE3-LAYERS], Section .7 and Annex C.
4.3. 4.3.5.
4.4. Service-Specific Requirements
4.4.1. Interworking
1. The encapsulation layer MUST support network interworking
between end services of the same type and Signaling
In accordance with [PWE3-FW] this specification considers only P2P
bi-directional bit-rate.
2. The encapsulation layer SHOULD remain unaffected by specific
characteristics of connection between the end services and network interworking.
4.3.1. CE Signaling
For unstructured TDM services, CE signaling is carried as part PE
devices at the two ends of the PW payload, and hence (see service examples in
Section 3.2.3 above).
4.4.2. Network Synchronization Schemes
The encapsulation layer MUST NOT be treated by applicable to all the PW mechanisms.
For structured TDM services considered network
synchronization schemes mentioned in this document CE signaling Section 3.2.2.
If the same high-quality synchronization source is terminated by available to all
the PE and does not have to be carried over devices in the PSN.
There is only one exception to these basic rules:
AIS or Idle Code (for both structured and unstructured services) MAY
not be carried "as is" over given domain the PSN. Instead, only appropriate
bandwidth-conserving AIS or Idle Code indications encapsulation layer SHOULD be sent.
CESoPSN provides appropriate mechanisms for this purpose.
Note: AIS is applicable
able to unstructured E1/T1 and E3/T3 services
while Idle Code is applicable for fractional E1/T1 and unstructured
E3/T3 services.
4.3.2. PE/PW infer additional benefits (e.g., facilitate better
reconstruction of the native service clock) from this fact.
TDM Circuit Emulation Service over PSN August 2002
4.4.3. CE Signaling
[PWE3-FW] defines PE/PW signaling as a mechanism used for PW setup
and teardown. This document does
Unstructured TDM services do not specify usually require any specific signaling special
mechanisms for this purpose carrying CE signals as it assumes that such a mechanism
belongs to these would be carried as part
of the common PW layer, while CESoPSN describes a certain
payload convergence layer. However, it defines a set emulated service.
Structured TDM services may require application-specific CE
signaling.
In some cases this signaling may require synchronization with the
data. E.g., code-associated signaling (CAS) reflects the state of parameters
describing payload
telephony applications (like off-hook and payload convergence layers on-hook) that MUST must be used
by
passed across the setup mechanism (see Section .7 below).
A tentative description emulated service and synchronized with data to
allow normal operation of the common PW these applications.
The encapsulation layer mechanisms SHOULD support signaling of state of CE
applications for setup the relevant services providing for:
o Multiplexing of application-specific CE signals and teardown data of PWs is given
the emulated service in Annex C.
TDM Circuit Emulation Service over PSN November 2001
4.4. the same PW OAM
4.4.1. Fault detection
o Synchronization (within the application-specific tolerance
limits) between CE signals and Handling
CESoPSN data at the PW provides for detection of a wide range of defects
(misconnection, loss of packets, mistype, egress
o Probabilistic recovery against possible accidental loss of synchronization) by
signaling packets in the outbound direction PSN
o Deterministic recovery of its IWF. These defects are signaled:
To the corresponding PWES and, eventually, to the CE
To the peer IWF at the other end of the PW.
Details are described in Section .7.7 below.
4.4.2. application state after PW Maintenance
CESoPSN format allows to set
setup and clear PW loopbacks. Details are
described in Section .7.6.3 below.
5. Specifics of Pseudo-Wire Emulation for PDH Circuits
In this section we discuss specific characteristics network outages.
Some types of PDH CE signaling associated with the TDM circuits (e.g., as opposed
performance monitoring requests and responses, requests to SONET/SDH circuits covered by [MALIS]) that
justify usage of dedicated techniques for carrying them in PW over
PSN.
5.1. Native Frame Size operate
and release loopbacks etc.) do not reflect application state and
hence do not require synchronization with data. As mentioned in [PWE3-FW], natural delineation for TDM services is a
time frame of 125 us. Data units produced by this delineation will consequence,
these signals can be
later referred passed out-of-band and do not have to as be
supported by the native circuit frames. When it comes to
packetization, difference in encapsulation layer.
The payload format for the line rates results in 'signaling' packets MAY be application-
specific.
4.4.4. Latency and Encapsulation Effectiveness
The encapsulation layer SHOULD allow for an effective trade-off
between the following
difference between requirements:
1. Effective PSN bandwidth utilization. Assuming that the circuit native frames of a high-rate TDM
circuit (e.g., SONET/SDH) and these of a low-rate one (e.g., T1/E1):
o Native circuit frames of high-rate TDM circuits in most cases
cannot be packetized into a single packet size of
encapsulation layer header does not depend on the underlying
PSN. E.g., the native frame size for an STS-3c SPE circuit is
2349 bytes. A STS-1 SPE circuit with of its native frame
payload, increase in the packet payload size of
783 bytes results in
increased efficiency.
2. Low edge-to-edge latency. Low end-to-end latency is probably a borderline case (exceeds the minimal IP
MTU defined in [RFC1122] but can be packetized in a single
packet common
requirement for most modern PSN types). As a consequence, PWs
handling these circuits must use some fragmentation techniques
o Native circuit frames of low-rate Voice applications over TDM services are relatively
short. E.g., the native frame size for an E1 circuit services.
Packetization latency is just 32
bytes. As a consequence, packing multiple native circuit frames
into a single packet one of the underlying PSN is both possible components comprising
edge-to-edge latency and
advantageous for effective PW operation (reduces overhead).
Packing of multiple native circuit frames into a single packet of the
underlying PSN results in the following effects:
1. It reduces overhead associated decreases with carrier, carrier convergence
and common PW headers the packet payload
size.
TDM Circuit Emulation Service over PSN November 2001
2. It saves August 2002
4.4.5. Fault Detection and Handling
The encapsulation layer for edge-to-edge emulation of TDM services
SHOULD, separately or in conjunction with the PSN switching capacity (i.e., number lower layers of packets per
second carried by the PW)
3. It may increase requirements on Path MTU between PE devices
4. It increases transport delay
pWE3 stack, provide for detection of the emulated circuit
5. It increases impact following defects:
1. Misconnection
2. Loss of loss packets. Special importance of a single packet on the service
outage time.
Actual packing factors (i.e., number detection of native circuit frames per
packet) will probably represent a trade-off between beneficial and
detrimental effects described above. E.g., packing factor introducing
1 ms packetization delay looks like a good enough trade-off for low-
rate services like E1 and T1.
5.2. Synchronization
[PWE3-FW] provides, this
defect has been explained in Section 4.4.2, classification of different
techniques 4.3.1 above
3. Malformed packets
4. Loss of clock recovery synchronization.
4.4.6. Performance Monitoring
The encapsulation layer for L1 PWs.
Some edge-to-edge emulation of these techniques explicitly depend upon availability TDM services
should provide for collection of a
common external clock. [PWE3-FW] notes that this "is not commonly
available in a performance monitoring (PM) data network or in a multi-carrier network".
Adaptive clock recovery does not depend upon availability of a common
external clock. However, since clock correction cannot occur more
than once per received packet, its convergence time
that is in inverse
proportion to compatible with the packet rate parameters defined for 'classic', TDM-
based carriers of these services (see [G.826] for details).
4.4.7. Bandwidth Saving
The encapsulation layer should provide for saving the PW. And, PSN bandwidth
by not sending invalid data.
4.4.8. Adaptation of course, the buffer
at Jitter Buffer
The encapsulation layer SHOULD allow adaptation of the PW egress must be sufficient jitter buffer
size to avoid overrun or underrun
during the convergence process, hence introducing additional delay.
RTP-based techniques (more complicated than ones described in [PWE3-
FW]) allow fast compensation actually observed level of initial discrepancy between line
clock at ingress and local oscillator of egress. Effectiveness of
these techniques depends upon:
o Quality the packets' inter-arrival
jitter while maintaining acceptable levels of local oscillators at PE devices. E.g., Stratum 4
local oscillators errors that are sufficient for recovering E1 and T1
clock
o Resolution of timestamps used
introduced by RTP.
5.3. Conclusion
Both effectiveness and faithfulness such an adaptation.
Note: The meaning of edge-to-edge emulation 'acceptable level of PDH
circuits over a PSN can be improved by errors' depends on the
application using a dedicated
encapsulation format that combines:
o Ability to pack multiple native circuit frames into the emulated service. In particular, Voice
applications can tolerate loss or insertion of a single
packet
o Ability octet in a
contiguous sequence of several non-erroneous octets. (In case of
insertion, it is customary to carry timestamps across repeat the PSN.
6. previous, non-erroneous,
octet.)
5. CESoPSN Encapsulation
6.1.
5.1. Generic CESoPSN Format
CESoPSN packets use format shown in Fig. 2 below.
TDM Circuit Emulation Service over PSN November 2001 August 2002
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-specific Carrier Header |
| ... |
| PW Demuxing Field PSN and multiplexing layer headers |
| ... |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Fixed |
+-- --+
| RTP |
+-- --+
| Header (see [RFC1889]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word (optional) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| .... |
| Packetized TDM data (payload) or maintenance commands/replies |
| .... CE signaling data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. CESoPSN Format
Usage of the CESoPSN Control Word is RECOMMENDED. However, PE peers
MAY agree not to use it in a specific CESoPSN PW as part of the PW
setup process.
Usage of the CESoPSN control word allows:
o To preserve bandwidth by not transferring absent data (AIS,
idle code)
o To signal problems detected at the PW egress to its ingress
o To carry maintenance (loopback) commands from PW ingress to
egress.
6.2.
5.2. CESoPSN Header
The CESoPSN header includes a fixed RTP header (12 octets) and an
optional CESoPSN Control Word (4 octets).
6.2.1.
5.2.1. Usage of RTP Header
CESoPSN uses the fields of the fixed RTP header (see [RFC1889],
Section 5.1) in the following way:
o V (version) is always set to 2
o P (padding) is used in accordance with rules described in
[RFC1889], Section 5.1 always set to 0
o X (header extension) is always set to 0
TDM Circuit Emulation Service over PSN November 2001
o CC (CSRC count) is always set to 0
o M (marker) is set to 0 to for CESoPSN packets carrying PDH
circuits. CESoPSN packets carrying unstructured SONET/SDH
circuits MAY set this bit to 1 to distinguish packets that
carry the framing octets
o PT (payload type) carries is used to distinguish between packets
carrying the packetized TDM data and packets carrying CE
signaling. At least one PT value should be allocated from the
range of dynamic values (see [RTP-TYPES]) for every CESoPSN
PW. Allocation is done during the PW type code defined setup and MUST be the
same for both PW directions. The PE at the PW ingress MUST set
the PT value in Section .
7.1 below. Egress the RTP header to the allocated value. The PE of a CESoPSN
at the PW egress MAY use this value to detect payload mistype
defects if it receives packets with malformed
packets. An additional PT value that differs from the service type of the PWES same range MUST be
allocated for CESoPSN PWs supporting in-band CE signaling (see
Section 5.3.2 below)
o Sequence number is used primarily to provide the common PW
sequencing function as well as detection of lost packets. It
is generated and timestamp processed in accordance with the rules
established in [RFC1889]
TDM Circuit Emulation Service over PSN August 2002
o Timestamp is used primarily for carrying timing information
over the network. Their values are used in accordance with the
rules established in [RFC1889]. Frequency of the clock used
for generating timestamps MUST be a multiple of 8 KHz KHz.
Possible modes of timestamp generation are discussed below
o The SSRC (synchronization source) value in the RTP header is
treated as logically belonging to the common PW header and MAY
be used for detection of misconnections if the Carrier
Convergence layer does not provide misconnections.
Note: The same PT value can be safely allocated for it. Accordingly it is
assigned different PWs.
The RTP header in CESoPSN can be used in conjunction with at least
the following modes of timestamp generation:
1. Absolute mode: the ingress PE sets time stamps using the clock
recovered from the incoming TDM bit stream
2. Differential mode: PE devices connected by the common PW layer. Rules have access
to the same high-quality synchronization source, and this
synchronization source is used for timestamp generation.
Usage of such an assignment
are other timestamp generation modes is left for further study.
6.2.2.
Absolute mode allows operation in the Asynchronous Carrier's Carrier
deployment scenario. Differential mode may improve quality of the
recovered clock in the One Synchronous Network and Synchronous
Carrier's Carrier deployment scenarios.
5.2.2. Usage and Structure of the Control Word
Structure
Usage of the CESoPSN control word allows:
o Differentiation between the PSN problems and the problems
beyond the PSN as causes for the emulated service outages
o Saving bandwidth by not transferring invalid data (AIS, idle
code)
o Signaling problems detected at the PW egress to its ingress
Consequently, usage of the CESoPSN Control Word is the recommended
default. The PE peers MAY agree not to use it in a specific CESoPSN
PW as part of the PW setup process.
Note: Alternative techniques for conveying forward and backward
indications without using the control word are left for further
study.
The structure of the CESoPSN Control Word is shown in Fig. 3 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|I|L|R|OAM|Z|
|0|0|0|0|A|I|L|T|Z| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Structure of the CESoPSN Control Word
TDM Circuit Emulation Service over PSN August 2002
o Bits 0-3 MUST be set to 0 at ingress and MUST be ignored at
egress
o Bit A - if carries Local AIS indication. If set, represents AIS
of the carried unstructured circuit. A packet with the A bit
set MUST NOT MAY carry any data no payload
o Bit I - carries Local Idle Code indication. If set, represents
the Idle Code in the payload of a N*DS0, a N*DS0 with CAS or
an unstructured T3 circuit. A packet with the I bit set MAY
carry no payload
o Bit L - carries remote Remote Loss of Packets indication of the PW
carrying CESoPSN, i.e., this bit is set in packets transmitted
by PE-2 to PE-1 if PE-2 detected loss of packets in the stream
received from PE-1
o Bit I - if set, represents the Idle Data in the payload of a
fractional E1/T1 or unstructured T3 circuit. A packet with the
I bit set MUST NOT carry any data
o Bit R T - if set, represents remote synchronization defects' carries Remote Synchronization Problem indication.
o Bits OAM are used to set and clear remote CESopSN loopbacks.
They are interpreted like following:
* 00 - a normal CESoPSN packet
* 01 - a command to the peer end point to set a CESoPSN
loopback. If this command is reliably received by the
outbound IWF, it begins transmitting back payload data it
receives from the PSN instead of packetized data of its
PWES. The IWF under a PW loopback continues to transmit
data received from the PSN to its PWES
* 10 - a command to clear a CESoPSN loopback. If this
command is reliably received by the egress that has been
TDM Circuit Emulation Service over PSN November 2001
working in the loopback mode, it resumes its normal
operation
* 11 - illegal value
o Bit Z - if set, indicates that the CESoPSN IWF operates under
a PW loopback command (regardless of the origin of this
command). If cleared, indicates normal CESoPSN IWF operation
o Reserved - for PDH circuits these bits SHOULD are reserved for possible future use.
Currently they MUST be set to 0 at ingress and MUST be ignored at
egress. These bits may be used
if an unstructured SDH circuit is carried in the CESoPSN
format, see Annex B.
Notes:
1. Either A or I bit (but not both) can be set in the CESoPSN
control word.
2. Some PDH circuits allow to set and clear loopbacks in the
remote device using in-band signaling. However, these signals
MUST NOT be translated into in-band PW loopback commands: for
structured circuits, they MUST be terminated by the local PE
(so that the loop in question will be set or cleared between
CE and its local PE) while for unstructured circuits they will
be carried "as is" to the remote CE (so that the loop will be
established between a pair of CE devices). PW loopbacks are
established between PE devices as described in Section .7.6.3
below.
3. Information about lost packets (carried via the L bit) can be
used at ingress as an indication of congestion in the
transport tunnel between ingress and egress PEs (see also to resynchronize CE
application state, see Section .9 below). If the PSN supports some traffic engineering
capabilities, such an indication may trigger creation of an
alternative transport tunnel bypassing congested links and/or
nodes.
6.3. 5.3.2 below.
5.3. Payload Data Format
A single CESoPSN packet always contains one or more native service circuit
frames of the carried circuit. This arrangement allows to emulate provides for emulation of
performance monitoring parameters of "classic" carriers of such a
circuit TDM
circuits (e.g., SONET/SDH).
Number
Note: The native circuit frames for all the circuits considered in
this document save from unstructured T1 are octet-aligned. The T1
native circuit frame (193 bits) is not, and hence requires special
treatment - see Section 5.3.4 below.
The PSN operator selects the number of native service frames in a
CESoPSN packet MUST be: for a specific PW taking into account the following
considerations:
o Packetization latency requirements vs. bandwidth utilization
(see Section 4.4.4 above)
o Path MTU limitations in order to avoid fragmentation of
CESoPSN packets
This specification assumes that the number of native service frames
in a CESoPSN packet is:
o Defined during the PW setup and remain remains constant for the
duration of a PW PW. Such an arrangement simplifies
implementation because it implies that the CESoPSN packets are
transmitted at a constant rate
TDM Circuit Emulation Service over PSN August 2002
o The same for both directions of the PW.
6.3.1. Fractional E1/T1 Such an arrangement
simplifies signaling and processing of backwards problem
indications.
5.3.1. Transparent N*DS0 Circuits
The payload data format for fractional T1/E1 transparent N*DS0 circuits is shown in
Fig. 4 below (N - number of timeslots in the circuit, M = number of
the native circuit frames in a CESoPSN packet, the 1st timeslot of
the 1st native frame is the 1st octet of the payload). The matrix
shown in this diagram is mapped into array of payload octets row by
row.
TDM Circuit Emulation Service over PSN November 2001
Timeslots ->| 1 | 2 | ... | N |
------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
N C F 1| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a i r 2| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t r a ...| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
i c m ...| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
v u e ...| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e i s ...| | | ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t M| | | ... | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4. Payload structure for a Fractional E1/T1 N*DS0 Circuit
6.3.2.
CESoPSN-based emulation of a transparent N*DS0 TDM circuit can be
considered as "bundling" of N independent DS0 circuits (see [PWE3-
REQ], Section 2.1.3).
The payload structure described provides for adaptation of the
jitter buffer size for Voice applications while maintaining
acceptable level of errors:
o Actual size of the jitter buffer can be decreased by
"shortening" the payload of some of the packets already in the
buffer by the one "row" (native circuit frame) when they are
transmitted. This is equivalent to dropping one octet from
each timeslot
o Actual size of the jitter buffer can be increased by
"lengthening" the payload of some of the packets already in
the buffer by one "row" (native circuit frames) when they are
transmitted. This is equivalent to insertion of a single octet
into each timeslot; the values carried in the last actual row
of the matrix are repeated.
TDM Circuit Emulation Service over PSN August 2002
5.3.2. N*DS0 circuits with CAS
A PW that emulates an N*DS0 circuit with CAS assumes that CE devices
are PSTN switches that synchronize the state of each of N DS0
channels using channel-associated signaling. This PW carries TDM
data in format described in the previous section.
In addition, it carries the CAS state vector of each CE in special
signaling packets using:
o An additional PT value allocated for this purpose from the
range of unused values (see [IANA]). This value MUST be
different from one allocated for the TDM data packets for the
same PW
o An additional SSRC value that MUST be different from one used
for the data packets in order to allow a separate numbering
sequence for the signaling packets
o A sequence numbering scheme that does not depend on one used
for the data packets. This allows re-use of common sequence
numbers-based mechanisms (like reordering and detection of
lost packets) for the data packets for all types of circuits
o The signaling payload format described in Fig. 5 below. Format
of the 32-bit timeslot signaling word is defined in [RFC2833]
Section 3.5 and Section 3.14, and numbering of timeslots
corresponds to that of the "columns" in the data packets'
payload, see Fig. 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeslot signaling word for TS-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeslot signaling word for TS-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeslot signaling word for TS-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Payload of a Signaling Packet for a N*DS0 Circuit with CAS
Note: The "volume" field defined in the [RFC2833] Section 3.5 is not
used with CAS events.
CESoPSN does not require handling of loss of signaling packets; as a
consequence, detection of loss of these packets is not required
either. On the other hand, the same synchronization source MUST be
used for timestamps in both signaling and data packets in order to
synchronize data and signaling within reasonable limits.
TDM Circuit Emulation Service over PSN August 2002
Signaling packets are generated by the ingress PE in accordance with
the following logic (adapted from [RFC2833]):
1. The CESoPSN signaling packet with the same information is
sent 3 times at an interval of 5 ms under one of the
following conditions:
a. The CESoPSN PW has been set up
b. A change in CAS state of one of the timeslots has been
detected. If another change of CAS state has been detected
during the 15 ms period, this process continues
c. Loss of packets defect has been cleared
d. Remote Loss of Packets indication has been cleared (after
previously being set)
2. Otherwise, the CESoPSN signaling packet with the current
CAS state information is sent every 5 seconds.
These rules allow fast probabilistic recovery after loss of a single
signaling packet as well as deterministic (but, possibly, slow)
recovery following PW setup and PSN outages.
5.3.3. Unstructured TDM Circuits
Basically, unstructured TDM circuits do not require framers in the
PE devices, and are transferred as bit streams. However, presence of
a framer allows detection of some outages of the carried circuit and
increase end services. As a
consequence, efficiency of CESoPSN.
Payload the CESoPSN operation under such outages
may be increased.
The payload of a CESoPSN packet carrying an unstructured TDM circuit
with an octet-aligned native circuit frame MUST contain a number of octets that is a multiple of the one or more
native frame
size circuit frames of the carried circuit, but no alignment with
the framing structure of the service is required.
6.3.3.
5.3.3.1 "T1-in-E1" Mode for Unstructured T1 Circuits
As mentioned above, unstructured T1 represents the only case of a
TDM circuit considered in this document with a non-octet aligned
native circuit frame. In order to accommodate this type of circuit
into the general CESoPSN MAY support framework, a special mode for transferring unstructured T1,
which is similar to "T1 in E1" mode payload
format (similar to one defined in [G.802]. Support of
this mode does not require framers in PE, and the resulting structure
of the CESoPSN payload data for this mode [G.802]) is used as shown in Fig. Fig 5
below (M = number of native frames in the CESoPSN packet, bit D is the most
significant bit of the octet in the 25-th column and is considered as
part of denotes
the payload data. data bits).
TDM Circuit Emulation Service over PSN November 2001 August 2002
"Timeslots" | 1 | 2 | ... | 24 | 25 |
|0 1 2 3 4 5 6 7|0 7| ... |0 1 2 3 4 5 6 7| ... |0 7|0 1 2 3 4 5 6 7|
------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
N C F 1| Data |D| 1|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a i r 2| Data |D| 2|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t r a ...| Data |D| ...|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
i c m ...| Data |D| ...|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
v u e ...| Data |D| ...|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e i s ...| Data |D| ...|D D D D D D D D| ... |D D D D D D D D|D| padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
t M| Data |D| M|D D D D D D D D| ... |D D D D D D D D|D| padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 5. 6. The "T1-in-E1" CESoPSN Payload structure for an Unstructured T1 Circuit Format
Note: This mode allows to overcome possible octet Each row in the matrix presented in Fig. 6 contains exactly
193 payload data bits (and 7 padding bits). However, no alignment
limitations of packetizers
the rows with the T1 framing structure is implied and de-packetizers.
7. CESoPSN Operation
Description hence support
of the CESoPSN operation assumes this mode does not require a reference model
similar to ones described T1 framer in [PWE3-FW], Section 4.1, Fig. 7 PE.
6. CESoPSN Operation
Note: This section includes non-normative information and
implementation considerations. These elements will be moved to an
appropriate Appendix in
[MALIS](the latter explicitly introduces jitter buffer), Section
6.1.1, Fig. 5. It includes the next update.
Edge-to-edge circuit emulation of a TDM circuit using CESoPSN
assumes the following elements:
o Two PW ESs (of end services of the same type and bit rate) rate
o Packetizer at the PW ingress
o Jitter buffer and de-packetizer at the PW egress.
In accordance with the generic PW setup scheme, the
Setup of a CESoPSN operation
description includes PW assumes exchange of the following elements: information:
o Definition Types of new end services. In order to be connected by a CESoPSN
PW, these types MUST be the same and define the PW type. PW
types (common supported by CESoPSN MUST be accommodated into the
common enumeration of PW layer) types
o Definition Bit rates of end services. In order to be connected, bit rates
of the payload layer-specific parameters two end services MUST be the same and their
compatibility rules define the PW bit
rate
o Definition Encapsulation layer-specific parameters that define specific
instantiation of the payload convergence layer specific protocol
This document defines how the values of these parameters
and their compatibility rules should be
encoded. The actual signaling protocols for exchanging these
parameters between the PE peers ("PE/PW signaling" in terms of
[PWE3-FW]) are out of scope of this document.
TDM Circuit Emulation Service over PSN August 2002
Description of the CESoPSN-based edge-to-edge circuit emulation
includes the following elements:
o Definition of the end service inactive state behavior towards
the CE
o Description of the IWF operation in inbound CE-bound and outbound PSN-bound
direction.
Details are presented below.
7.1. New
6.1. Payload Parameters
6.1.1. PW Types Type
PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW
types used for CESoPSN PW are assigned taking into consideration
that:
o They belong in such a way as to the common PW layer. Hence there should be no avoid
overlap with types assigned in other PWE3 documents
TDM Circuit Emulation Service over PSN November 2001
o They are carried in the PT field of the RTP header. Hence they
should be limited to 7 bits and produce no overlap with the RTP
payload types assigned/reserved by IANA (see [RTP-TYPES]). documents.
The following PW types are hence defined in this document for
CESoPSN: CESoPSN-
based PWs:
o Fractional E1/T1 Transparent N*DS0 - 65
o N*DS0 with CAS - 65. 66
o Unstructured E1 - 66 67
o Unstructured T1, bit stream mode - 67 68 (not defined in this
specification)
o Unstructured T1, T1-in-E1 mode - 68 69
o Unstructured E3 - 69 70
o Unstructured T3 - 70 71
o Unstructured SONET/SDH - 71 72 (see Annex B).
6.1.2. Circuit Bit Rate
The circuit bit rate is encoded as the number of "timeslots" in the
matrix structure of the corresponding CESoPSN setup mechanism MUST NOT allow establishment data packet.
The following values are used:
o Transparent N*DS0 - N, 1 <= N <= 31
o N*DS0 with CAS - N, 1 <= N <= 30
o Unstructured E1 - 32
o Unstructured T1, T1-in-E1 mode - 25
o Unstructured E3 - 537
o Unstructured T3 - 699
o Unstructured STS-1 - 810
o Unstructured STM-1 - 2430
Note: N*DS0, unstructured E1 and unstructured T1 circuits can be
carried over any PSN implementing the minimal MTU as defined in
[RFC1122]. Unstructured E3 and T3 can be carried over any PSN
providing Path MTU of a PW 1.5 Kbytes. Unstructured STS-1 and STM1 are
considered in Annex A.
TDM Circuit Emulation Service over PSN August 2002
6.2. Encapsulation Layer Parameters
6.2.1. Usage of a
certain type between end services if at least one Control Word
TRUE value (default) of them does not
suit this type.
7.2. Circuit Bit Rate
Circuit Bit Rate is a Boolean parameter means that describes specific the
CESoPSN control word is used.
CESoPSN MAY allow negotiation of this parameter, so that the control
word will not be used if both sides agree to that.
6.2.2. RTP Payload
Layer. It Type
1. One PT value MUST be a 16-bit integer representing allocated from the bit rate range of
dynamically allocated payload types for each CESoPSN PW for
use in the
end service data packets:
a. The same value MUST be allocated for both directions of
the PW
b. Ingress PW MUST set the PT in the RTP header of all the
data packets to the allocated value
c. Egress PW MAY use this value to detect non-data PW
packets. These packets can be either relegated to
signaling or considered as multiple malformed
2. For emulation of a N*DS0 circuit with CAS, an additional PT
value MUST be allocated from the basic rate range of 64 Kbit/s.
Note: This definition scales up to 4 Gbit/s. This by far exceeds both
the presently defined dynamically
allocated payload types for each CESoPSN and its possible extensions.
Note: This parameter PW for use in the
data packets:
a. It MUST be set to 25 for an unstructured T1 circuit
Compatibility rule different from the PT value allocated for this parameter states that it data
packets
b. The same value MUST be same allocated for both end services of a prospective PW.
7.3. Usage directions of Control Word
This is a Boolean parameter that described payload convergence layer
the PW
c. Ingress PW MUST set the PT in the RTP header of a CESoPSN PW. TRUE value (default) means that all the CESoPSN control
work is used.
CESoPSN
signaling packets to the allocated value
3. Egress PW MAY allow negotiation of use this parameter, so that the control
word will not be used if both sides agree value to that.
7.4. Common L1 (Circuit)PW Layer Parameters
7.4.1. distinguish signaling PW
packets.
Note: The same PT value may be allocated for multiple PWs.
6.2.3. Payload Bytes
This parameter has been defined in [MARTINI-TRANS]. Compatibility
rules include In order to
establish a CESoPSN-based PW, the following: following conditions MUST be met:
o This parameter The number of payload bytes MUST be the same for both
directions of the PW
o This parameter The number of payload bytes MUST be a multiple of the encoded
Circuit Bit Rate (see Section 6.1.2 above). E.g., the value of
this parameter for an Unstructured E1 circuit (Circuit Bit Rate
= 32) with N M native circuit frames
TDM Circuit Emulation Service over PSN November 2001 packet into a single CESoPSN
packet will be 32*N, 32*M, while for an Unstructured T1 it will be 25*N
25*M
o The size of the resulting PW packet (including all the headers) MUST
SHOULD NOT exceed the path MTU between the participating PEs as
provided by the Carrier layer.
7.4.2. Synchronization Clock Rate
This
TDM Circuit Emulation Service over PSN August 2002
Note: For N*DS0 with CAS circuits this parameter defines the number
of payload bytes in the data packets only. The number of payload
bytes in the signaling packets is a 16-bit integer representing inferred from the encoded circuit
bit rate in the obvious way.
6.2.4. Timestamp Resolution
This parameter encodes the synchronization
clock rate of the clock used for setting
timestamps in RTP headers as a multiple of the basic 8 KHz rate.
6.2.5. Synchronization Source ID
The same 32-bit SSRC value MUST be assigned to all the data packets
of a given direction of a CESoPSN MAY allow
negotiation PW. The CE-bound direction of the
IWF MAY be use this parameter value for misconnection detection, especially if two different values have been
initially specified by end services. (If negotiation
such a service is allowed, not provided by the
PW MAY eventually PSN and/or multiplexing
layer(s).
If data and signaling packets are multiplexed in the same PW, the
signaling packets MUST use a separate SSRC value. This arrangement
complies with the clock rate value, which is RTP specification [RFC 1889] and allows effective
compression of the PW headers by the standard compressors.
6.2.6. Timestamp Generation Mode
This parameter accepts at least common
denominator of the following two suggested values.)
7.5. values
corresponding to operation modes described in Section 5.2.1:
o Absolute (1)
o Differential (2).
6.3. End Service Inactivity Behavior
While inactive, each the PW is inactive:
o Each unstructured end service MUST send AIS to its prospective CE.
CE
o Each structured end service MUST send an appropriate Idle Code is sent
to its prospective CE in case of a fractional E1/T1
end service.
7.6.
6.4. Description of the IWF operation
Once started, the PW is set up, the CESoPSN IWF operates like following:
7.6.1. Outbound
6.4.1. PSN-bound Direction
1. End service data is packetized in accordance with the number
of payload bytes specified. For fractional E1/T1 N*DS0 services,
chunks of the
packetized data are aligned with the native circuit frames as
described in Section .6.3.1 5.3.1
2. Sequence numbers and timestamps representing the selected
synchronization clock are inserted in the CESoPSN headers
TDM Circuit Emulation Service over PSN August 2002
3. CESoPSN, Carrier Convergence multiplexing and Carrier PSN headers are prepended to the
packetized circuit data
4. Resulting packets are transmitted via the PSN
5. If the end service PE detects any outage of conditions the incoming an unstructured
end service that natively
produce would result in sending the
"downstream AIS" condition (LOS, LOF, AIS), AIS", the CESoPSN IWF MAY, instead of packetizing AIS, send just packet
with using the control word MUST
set the local AIS indication flag set (bit A) in the control word.
The packet payload MAY be omitted in order to its peer. save the PSN
bandwidth.
6. If the inbound direction of a T3 end service PE detects an Idle Code condition, condition of the incoming an
unstructured T3 end service, or an AIS-producing condition is
detected in the incoming 'carrier service' of an N*DS0 end
service, the CESoPSN IWF MAY, instead of packetizing
Idle Code, send just packet with using the control word MUST set the
local Idle Code indication flag
set to its peer.
Note: LOS detection of (bit I) in the end service does not require a framer control word.
The packet payload MAY be omitted in a
PE. order to save the PSN
bandwidth.
Local AIS detection and Idle Code indications in the CESoPSN control word
provide for E1/T1 the following functionality:
o Ability to distinguish between the PSN problems and E3 also does ones
beyond the PSN as causes of outages of the emulated service
o Ability to save the PSN bandwidth (but not require framer,
while AIS detection for T3 does. LOF detection (for all types its switching
capacity) by not sending invalid data across the PSN.
The techniques to save the PSN switching capacity in case of
services) and Idle Code detection (for T3) also require a framer.
7.6.2. Inbound an end
service outage are left for further study.
6.4.2. CE-bound Direction - Normal Operation
TDM Circuit Emulation Service over PSN November 2001
1. The inbound CE-bound IWF includes a jitter buffer that accumulates
data from incoming CESoPSN packets with their respective
timestamps. The length of this buffer SHOULD be configurable
to allow adaptation to various network delay behavior
patterns. Size of the jitter buffer is a local parameter of
the CESoPSN payload convergence layer at each end IWF. Since any CESoPSN data packet carries a fixed
number of native data frames of the emulated service, the
jitter buffer can be considered as a PW matrix with "rows"
corresponding to native service frames, too.
2. Initially the Jitter buffer is filled with the appropriate
inactivity (AIS or Idle) code.
3. Immediately after start, IWF:
a. Begins reception of incoming CESoPSN packets. Carrier,
Carrier convergence PSN and common PW
multiplexing layer headers are stripped from the received
packets, and packetized TDM data from the received packets
is stored with the timestamps in the jitter buffer
b. Continues to play out its appropriate inactivity code into
its end service as long as the jitter buffer has not yet
accumulated sufficient amount of data
c. Signals the outbound CE-bound direction of the local IWF to transmit
CESoPSN packets with the T bit R set
3. (if control word is
used)
4. Once the jitter buffer contains sufficient amount of data
(usually half of its capacity), the IWF starts replay of this
TDM Circuit Emulation Service over PSN August 2002
data in its end service in accordance with its (locally
defined) 8 KHz transmission clock, so that a single "row" of
the jitter buffer matrix is replayed per "tick" of the clock.
At the same moment it signals the
outbound PSN-bound direction of IWF
to clear R the T bit in the CESoPSN packets it transmits
4. (if the
control word is used)
5. If transmission clock must be recovered, recovered from the timestamps stored
with PW, the
timestamps of data are packets SHOULD be used for this purpose
5. Inbound correcting
initial transmission clock frequency in accordance with the
specified mode of their generation.
6. If adaptation of the jitter buffer size is implemented, it
SHOULD NOT introduce additional wander of the transmission
clock. It MAY introduce additional errors (e.g., in accordance
with the techniques described in Section 5.3.1 above)
7. The CE-bound direction of the CESoPSN IWF performs monitoring IWF:
a. Performs detection, correlation and handling of CESoPSN
faults as described in Section 6.5 below
b. Collects the PW Performance Monitoring data as defined in
Section .7.7.
7.6.3. Inbound-to-Outbound 6.6 below
8. CE application state signals received in the signaling packets
SHOULD be synchronized with data using the timestamps and
inserted (in an appropriate format) into the CE-bound TDM
stream. Signals that cannot be inserted into the CE-bound TDM
stream due to the local format limitations MUST BE ignored.
Any aspects of translation of values of CE signals are out of
scope of this specification.
6.4.3. IWF Loopback
An Inbound-to-Outbound IWF loopback for the CESoPSN IWF MAY be set and cleared either by an
external (management) or an in-band command.
Once such a loopback is set, the outbound IWF will replace packetized
TDM data loop packets coming from
the CE with data received by the inbound IWF
from PSN back to the PSN. In addition it will mark these packets by
setting Z bit in the CESoPSN control word.
Once the loopback is cleared, the IWF resumes its normal operation.
7.7.
6.5. CESoPSN Defects
7.7.1. Precedence of Faults
Various CESoPSN faults are detected in accordance with a predefined
precedence, i.e., if a fault with a higher precedence has been
detected, faults of lower precedence are ignored.
The following precedence MUST be maintained between various CESoPSN
faults:
o
6.5.1. Misconnection (if is enabled)
o Loss
Some combinations of packets
o Payload mistype (if enabled)
TDM Circuit Emulation Service over PSN November 2001
o Loss of synchronization.
7.7.2. Misconnection
Misconnection is detected by the PW egress if it receives a packet
which has not been originated by what is considers to be the
legitimate ingress of this PW. It may be caused by any of the
following reasons:
o PW mis-configuration
o DoS attacks
o Network mis-configuration
o Forwarding errors (both in the network and in the egress PE)
o "Stray packets" in the core PSN. These may appear due to fast
reuse of identifiers used by egress PE for demuxing specific
PW.
Some demuxing techniques (UDP/IP, L2TPv3/IP) multiplexing layers (see Annex A)
inherently provide for
ingress identification, while others (e.g., MPLS/MPLS) require
carrying such identification in detection of packets that do not belong to
the common PW header (at least
logically). ('stray packets').
CESoPSN MAY detect misconnection faults using use the SSRC field in the RTP header regardless for detection of
'stray packets' even if such a capability is provided by the Carrier/Carrier Convergence
layers it uses.
CESoPSN packets carrying 0 value
specific combination of SSRC MUST NOT be checked for
misconnection using SSRC.
CESoPSN packets with detected misconnection PSN and multiplexing layers.
Regardless of the way in which a stray packet has been detected:
o It MUST be discarded with by the CE-bound IWF
o A counter of such packets incremented. 'stray packets' must be incremented
TDM Circuit Emulation Service over PSN August 2002
o If the misconnection condition reception of stray packets persists, an appropriate the Misconnection
alarm indication SHOULD should be sent reported to the management system.
CESoPSN
The IWF mechanisms for detection of lost packets with detected misconnection (e.g., expected next
sequence number) MUST NOT affect the
outbound IWF functionality regarding loss be affected by reception of packets detection.
7.7.3. 'stray packets'.
6.5.2. Re-Ordering and Loss of Packets and Re-Ordering
CESoPSN uses packet implementations SHOULD use sequence numbers in the RTP fixed
header and
locally defined timeouts expected rate of transmission of data packets for
detection of: of our-of-order delivery and packets' loss. In particular,
they MAY maintain the next expected sequence number value that would
be:
o Out-of-order packets Advanced every time a packet belonging to this PW with an
equal or greater (mod 65536) sequence number has been received
or a timeout defined by the expected packet arrival rate has
expired
o Lost packets
Detailed specification Used as the center of rules a sliding window for detection of packet loss is left
for further study.
Note: CESoPSN implementations reordering.
The size of this window SHOULD support be limited reordering. Only
out-of-order by the size of the
jitter buffer.
Out-of-order packets that cannot be reordered MUST be considered as
lost.
If loss of one or more CESoPSN packets has been detected at the
egress of the CESoPSN PW, its jitter buffer MUST be filled with the
appropriate amount of the AIS (or Idle) Idle - depending on the service
type) code to be replayed into the relevant PWES. In addition:
o Counter of lost packets must be updated
TDM Circuit Emulation Service over PSN November 2001
o If the loss-of-packets condition persists, an alarm SHOULD be
sent to CESoPSN control word is used, the management system
o Remote lost packets indication Lost Packets
Indication flag SHOULD (bit L) MUST be set in the next packet to be send
sent in the opposite direction of the service.
Note: In accordance with the general precedence principle, packets
with a misconnection problem MUST NOT affect expected sequence number
used for detection PW
o A counter of lost packets.
7.7.4. Payload Mistype
Payload mistype is detected by packets must be incremented
o If the outbound direction of loss-of-packets condition persists, an alarm should be
sent to the management system.
6.5.3. Malformed Packets
CESoPSN PW IWF
if it receives detects a malformed packet with PW type or payload size that it does not
expect.
Payload mistype may be caused by:
o Mis-configuration
o Problems at ingress or egress PE
CESoPSN SHOULD detect payload mistype faults if: using the following rules:
o The PT value in the its RTP header differs from expected or 0 does not correspond to one
of the PT values allocated for this PW
o The combination of Carrier/Carrier Convergence layers allows
definition actual packet payload size can be unambiguously
inferred from the data link, PSN or multiplexing layer of
the payload size, PW and this size does not
correspond to match the Payload Bytes parameter payload size defined for the specified
service.
packets of this type in this PW.
If an a malformed in-order packet with a payload mistype problem has been received at the egress of a
CESoPSN PW, then:
o Its jitter buffer MUST be filled with the appropriate amount
of the AIS (or Idle) code replay to be replayed into the
relevant PWES
o Counter A counter of payload mistype malformed packets must be incremented
o If the payload mistype condition persists, an appropriate
alarm
SHOULD should be sent to the management system.
7.7.5.
TDM Circuit Emulation Service over PSN August 2002
6.5.4. Loss of Synchronization
The CESoPSN IWF MAY detect two types of loss of synchronization
errors:
6.6.5.1.
6.4.5.1 Jitter Buffer Overrun
This fault is detected if the jitter buffer at the PW egress of CESoPSN cannot
accommodate the newly arrived CESoPSN packet in its entirety.
A CESoPSN packet that cannot be stored in the jitter buffer MUST be
discarded.
o
If the jitter buffer overrun condition persists, an appropriate
alarm SHOULD should be sent to the management system. In addition, the
Remote Loss of Synchronization (bit R) T) flag SHOULD be set in the
next packet to be send in the opposite direction of the service.
TDM Circuit Emulation Service over PSN November 2001
6.6.5.2.
6.5.4.2. Jitter Buffer Underrun
This fault is detected if the jitter buffer at the PW egress of CESoPSN becomes
empty before arrival of a new CESoPSN packet.
Mis-connection, packets loss, or reception packet while loss of packets with payload
mistype defects SHOULD NOT result in
has not been detected. CESoPSN implementations MAY never detect the jitter buffer underrun since
erroneous or lost packets would be replaced by an appropriate amount
of AIS/idle code data.
Jitter Buffer Underrun condition if their packets' loss detection
mechanisms do not allow it.
If the jitter buffer underrun condition persists, an appropriate
alarm SHOULD should be sent to the management system. In addition, the
Remote Loss of Synchronization (bit R) T) flag SHOULD be set in the
next packet to be send in the opposite direction of the service.
7.8. QoS Issues
As mentioned in Annex C below,
6.6. Performance Monitoring
6.6.1. Errored Data Blocks
[G.826] defines the PW setup process may receive
identification concept of an errored data block that serves as
the PHB to be used basis of for collection of performance monitoring parameters. It
also defines the specific PW size of the data block for most TDM circuits. These
definitions are aligned with the 'native circuit frame' size of
these circuits so that every G.826-compatible data block contains an
integer multiple of native circuit frames, e.g.:
o For E1 and use T1 circuits, a data block contains 4 native service
frames
o For E3 and T3 circuits, a data block contains one native
service frame etc.
The following definitions of error events and errored data blocks
for CESoPSN provide for collection of [G.826]-compatible performance
monitoring parameters:
o An error event is insertion of a single native service frame
of inactivity code into the jitter buffer if it
to request appropriate Carrier header does not stem
from receiving a CESoPSN packet with an AIS or Idle Code
indication
TDM Circuit Emulation Service over PSN August 2002
o An errored data block is a data block defined in accordance
with [G.826] that has experienced at least one error event.
6.6.2. Errored, Severely Errored and Unavailable Seconds
The definition of an errored data block presented above can be used
to define Errored Seconds, Severely Errored Seconds and Unavailable
Seconds in accordance with [G.826].
6.7. QoS Issues
If the Carrier layer. PSN providing connectivity between PE devices is Diffserv-
enabled and implements EF PHB (see [RFC2598bis]) SHOULD [RFC2598bis]), all the CESoPSN
data packets should be always used marked for setup EF PHB at ingress. Such an
arrangement results in decrease of CESoPSN
PWs if it is implemented the packets' inter-arrival jitter
and hence in decrease of latency introduced by the PSN.
8. TDM circuit
emulation.
7. RTP Payload Format Considerations
In accordance with guidelines specified in [RFC2736], the following
issues are addressed by this specification:
8.1.
7.1. Resilience to moderate loss of individual packets
Impact
The impact of loss of an individual data packet may be decreased by
decreasing the packet size (with the associated loss of efficiency). In
particular, limiting the packet size
Resilience to 1 ms (i.e., carrying 8 native
frames of the carried PDH service) will result in service outage of
50 ms in the presence loss of a 5% an individual signaling packet loss (the benchmark value
discussed is provided for
by the rules described in [RFC2736]).
8.2. Section 5.3.2 above.
7.2. Ability to interpret every single packet
This requirement is met for PDH services since every CESoPSN packet carries a
multiple of the native frame of the carried service.
8.3.
7.3. Non-usage of the RTP Header Extensions
This recommendation is met, since RTP-wise, the CESoPSN Control Word
is part of the RTP payload. In addition, alignment Alignment with this requirement
facilitates usage of standard header compression mechanisms if
CESoPSN uses UDP/IP as its Carrier Convergence/Carrier
layer (see below).
TDM Circuit Emulation Service over PSN November 2001
8.4. Treatment of the decoder internal data-driven state
This requirement is met by using the CESoPSN Control Word that
conveys such encoder internal states as AIS.
8.5. and multiplexing layers.
7.4. Compression of RTP headers
Existing relevant standards ([RFC2508], [RFC3095]) deal with
compression of RTP/UDP/IP headers on specific P2P links. Compression
techniques defines defined in these documents is are fully applicable for
CESoPSN if it uses UDP/IP as Carrier Convergence/Carrier layer. PSN and multiplexing layers
respectively. Standard compression of CESoPSN/UDP/IP headers will be
very effective, since:
o Value of the SSRC field in the CESoPSN header of data packets
remains constant for the duration of a CESoPSN session
TDM Circuit Emulation Service over PSN August 2002
o Value of the Timestamp field in the CESoPSN header is usually
incremented by a fixed value from packet to packet
o CESoPSN control word is NOT defined as RTP header extension.
On the other hand, link capacity gain for some typical CESoPSN PWs is
minimal, e.g.:
o If CESoPSN is used to carry an unstructured E1 circuit with
packetization delay of 1 ms, even total removal of the RTP
header would result in gaining about 92 Kbit/s of the link
capacity, i.e., less than 0.01% of capacity of a Gigabit
Ethernet link.
o Link capacity gain achieved by total removal of the RTP
header from CESoPSN carrying an unstructured T1 circuit in
the "T1-in-E1" mode would be about 88 Kbit/s.
As a consequence, a PSN-independent end-to-end compression technique
of RTP headers seems not justified.
9.
8. Congestion Control (RFC 2914) Conformance
CESoPSN PWs carry constant bit rate (CBR) services. These services,
by definition, cannot behave in a TCP-friendly manner prescribed by
[RFC2914] under congestion while retaining any value for the user.
Devices implementing CESoPSN and using IP as their Carrier Layer: PSN layer:
o MUST set the ECN bits of the IP header (see [RFC3168]) to
non-ECT non-
ECT ('00') value at ingress (to prevent routers in the network
from setting them to the CE ('11') value
o SHOULD ignore these bits at egress.
10.
9. FFS Issues
Note: This section will be removed from the final revision of the
document.
The following issues will be addressed in the next revisions of this
document:
TDM Circuit Emulation Service over
o Techniques for saving the PSN November 2001 switching capacity when the PW
experiences an end service outage or does not carry any valid
data
o Usage of RTCP
o Fractional E1/T1 with CAS (if found RTCP. One particular application to be considered is
retrieval of sufficient
interest)
o Explicit specification of rules for detecting loss of packets remote problems' indications without the control
word
o Effect of timestamp resolution on quality of clock recovery.
11. recovery in
Differential mode.
10. Security Considerations
This document does not affect the underlying security issues of
specific PSN.
In addition, it defines mis-connection and payload mistype misconnection detection capabilities of
CESoPSN. These capabilities increase resilience of CESoPSN to mis-configuration
misconfiguration and some types of DoS attacks.
12.
11. Applicability Statement
CESoPSN is a payload convergence an encapsulation layer intended for carrying PDH TDM circuits (fractional E1/T1,
(transparent N*DS0, transparent N*DS0 with CAS, unstructured E1/T1
and unstructured E3/T3) over packet-switching networks. PSN.
Applicability of CESoPSN MAY be extended to low-rate SONET/DH SONET/SDH
circuits with minimal modifications.
CESoPSN allows to conserve switching capacity of the PSN (i.e.,
number of packets per second handled by the PSN per a PW) by using
configurable packetization delay that is not limited by encapsulation
techniques. It also allows to conserve the
TDM Circuit Emulation Service over PSN bandwidth in case of
outages of the end service. August 2002
CESoPSN allows to carry carrying both data and clock of PDH TDM circuits across
multiple types of PSN.
CESoPSN allows carrying CE signaling that requires synchronization
with data (e.g., channel-associated signaling (CAS) for Voice
applications) in-band in separate signaling packets. The RTP Payload
Type (PT) is used to distinguish between data and signaling packets,
while the Timestamp field is used for synchronization. This makes
CESoPSN extendable to support different types of CE signaling
without affecting the data path in the PE devices.
CESoPSN does not presume availability of a global synchronous clock
at the ends of a PW. This makes it suitable for Asynchronous
Carriers' Carrier
applications when multiple CESoPSN PWs must carry data and clock
between otherwise isolated areas of PDH networks belonging to
different customers, each with its own synchronization scheme. applications.
CESoPSN uses RTP for carrying the clock across the network. As a
consequence, its jitter buffer is only used to compensate the packet
inter-arrival jitter introduced by the PSN and does not introduce PSN. The
additional delay for compensation of discrepancy between the ingress
end service line clock and egress PE local oscillator. This makes it
specially suitable for emulation of TDM circuits carrying delay-
sensitive (e.g., Voice) applications.
Standard RTP header is extended to the CESoPSN header in (if used) is a way that
guarantees applicability of payload format header and
hence standard header compression techniques for RTP/UDP/IP profile
over links slow and/or error-prone links. links are fully applicable to
CESoPSN PWs.
CESoPSN allows the PSN bandwidth conservation by carrying only AIS
and/or Idle Code indications instead of data.
Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP-
friendly behavior under network congestion.
TDM Circuit Emulation Service over PSN November 2001
CESoPSN allows collection of TDM-like faults and performance
monitoring parameters hence emulating traditional 'classic' carrier services of
PDH
TDM circuits (e.g., SONET/SDH). Similarity with these services is
increased by the CESoPSN ability to carry Far End Error 'far end error'
indications.
CESoPSN provides for a carrier-independent ability to detect mis-
connections
misconnections and payload mistype errors. malformed packets. This feature increases
resilience of the emulated service to mis-configuration misconfiguration and DoS
attacks.
CESoPSN provides for detection of lost packets and hence allows to
distinguish between the PSN problems and ones beyond the PSN as
causes of outages of the emulated service.
Faithfulness of a CESoPSN PW is may be increased if the carrying PSN is
Diffserv-enabled and implements EF PHB. In this case, all the CESoPSN
packets SHOULD be EF-marked.
CESoPSN does not provide any mechanisms for protection against PSN
failures. Hence its
outages. As a consequence, resilience of the emulated service to
such failures outages is defined
exclusively by that the PSN behavior. On the other hand, the
jitter buffer and packets' reordering mechanisms associated with
CESoPSN increase resilience of the emulated service to fast PSN itself.
13.
rerouting events.
TDM Circuit Emulation Service over PSN August 2002
12. IANA Considerations
This specification requires assignment of new PW Types/RTP Payload Types for CESoPSN
PWs as described in Section .7.1.
14. 6.1.
13. Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions. Axerra Networks, Inc. has filed one or more patent
applications relating to the CESoPSN technology outlined in this
document. Where there is a necessary dependence upon such patents
and patent applications in implementing an IETF adopted standard
resulting from this document, Axerra Networks will license on fair,
reasonable, and non-discriminatory terms to all parties, any patent
claims it owns covering such technology, solely to the extent such
technology is essential to comply with such standard. Any such
license to a party shall start on the date that Axerra Networks and
the party enter into an agreement related thereto and shall be
granted on the condition that any such party grants to Axerra
Networks and its corporate affiliates a reciprocal license under
such party's patents for which there is also a necessary dependence.
ACKNOWLEDGEMENTS
The authors would like to
We express deep gratitude to Stephen Casner who reviewed this
document in detail, corrected some serious errors and provided many
valuable inputs. Some of his inputs will be explored in the next
revisions of the draft.
We thank Sim Narasimha and Yaron Raz for valuable feedbacks.
We thank Alik Shimelmits for many fruitful discussions.
REFERENCES
[PWE-REQ]
[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
TDM Circuit Emulation Service over PSN November 2001
[PWE-FW]
[PWE3-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation
Edge-to-Edge (PWE3), Work in progress, September 2001, draft-pate-
pwe3-framework-02.txt February 2002, draft-ietf-
pwe3-framework-00.txt
[PWE3-LAYERS], Stewart Bryant et al., Protocol Layering in PWE3,
Work in Progress, February 2002, pwe3-protocol-layering-01.txt
[MALIS] Andrew G. Malis et al, SONET/SDH Circuit Emulation Service
Over MPLS (CEM) Encapsulation, Work in progress, April 2001, draft-
malis-sonet-ces-mpls-04.txt
[PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over
Packet (CEP), Work in progress, September 2001, draft-malis-pwe3-
sonet-00.txt
[PATE-TDM] P. Pate, R. Cohen, D. Zelig,
TDM Service Specification for
Pseudo-Wire Circuit Emulation Edge-to-Edge (PWE3), Work in Progress,
September 2001, draft-pate-pwe3-tdm-00.txt
[ANAVI-TDM] M. Anavi et al, TDM Service over IP, Work in Progress, September
2001, PSN August 2001, draft-anavi-tdmoip-02.txt 2002
[KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001,
draft-kompella-ppvpn-l2vpn-00.txt
[MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over
MPLS, Work in progress, June November 2001, draft-martini-l2circuit-
trans-mpls-08.txt
[MARTINI-ENCAP] Luca Martini et al, Encapsulation Methods for
Transport of Layer 2 Frames Over MPLS, Work in progress, November
2001, draft-martini-l2circuit-trans-
mpls-07.txt draft-martini-l2circuit-encap-mpls-04.txt
[L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in
progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt
[BRYANT-LAYERS] S. Bryant, L. Wood, Protocol Layering in PWE3, Work
in progress, November 2001, draft-bryant-pwe3-protocol-layer-00.txt
[RFC1122] R. Braden (ed.), Requirements for Internet Hosts --
Communication Layers, RFC 1122, IETF, 1989
[RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-
Time Applications, RFC 1889, IETF, 1996
[RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement
Levels, RFC 2119, IETF, 1997
[RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC 2434, IETF, 1998
[RFC2474] K. Nichols et al., Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474,
IETF, 1998
[RFC 2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links, RFC 2508, IETF, 1999
[RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP
Payload Format Specifications, RFC 2736, IETF, 1999
TDM Circuit Emulation Service over PSN November 2001
[RFC2598bis] Bruce Davie (ed.), An Expedited Forwarding PHB, Work in
Progress, April 2001, draft-ietf-diffserv-rfc2598bis-01.txt
[RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF,
2000
[RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC
3095, IETF, 2001
[RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC
3140, IETF, June 2001
TDM Circuit Emulation Service over PSN August 2002
[RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of
Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001
[RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp-
parameters
[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.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
[T1.103] ANSI T1.103 - 1987. Digital Hierarchy - Synchronous DS3
Format Specification
[T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface
Rates and Format Specifications (SONET}
[T1.107] ANSI T1.107 - 1988. Digital Hierarchy - Format
Specification
[T1.107a] ANSI T1.107a - 1990. Digital Hierarchy - Supplement to
Format Specifications (DS3 Format Specifications). Specifications)
[NANOG] St. Casner, C. Alaettinoglu, Ch. Kuan, A fine-grained view
of high-performance networking, NANOG-22, May 2001
AUTHORS' ADDRESSES
Alexander ("Sasha") Vainshtein
TDM Circuit Emulation Service over PSN November 2001
Axerra Networks
24 Raoul Wallenberg St.
Tel Aviv 69719, Israel
email: sasha@axerra.com
TDM Circuit Emulation Service over PSN August 2002
Israel Sasson
Axerra Networks
24 Raoul Wallenberg St.
Tel Aviv 69719, Israel
email: israel@axerra.com
Akiva Sadovski
Axerra Networks
24 Raoul Wallenberg St.
Tel Aviv 69719, Israel
email: akiva@axerra.com
Eduard Metz
KPNQwest
Scorpius 60
2130 GE Hoofddorp, The Netherlands
email: eduard.metz@kpnqwest.com
TDM Circuit Emulation Service over PSN November 2001
Tim Frost
Zarlink Semiconductor
Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK
email: tim.frost@zarlink.com
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
TDM Circuit Emulation Service over PSN August 2002
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.
ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN
A1. IP PSN
CESoPSN is RTP-based, and UDP flows are a natural way to convey RTP
traffic (see [RFC1889]).
If this technique is used for conveying CESoPSN, then:
o Unused even UDP ports must be allocated at both PE nodes
terminating a CESoPSN PW as part of the PW establishment
process
o IP and UDP headers must be prepended to each CESoPSN packet
o These packets will be transmitted by each PE node to its peer
using the standard IP routing mechanisms.
UDP flows represent a Carrier Convergence multiplexing layer with inherent limited ability to
detect misconnections. As a consequence, SSRC-based misconnection
detection by CESoPSN MAY be disabled.
IP represents a Carrier layer with inherent ability to infer the
payload size from the header. As a consequence, payload mistype detection of
malformed packets SHOULD take the actual payload size into
consideration.
By default, manual signaling can be used for setup and teardown of
CESoPSN PWs over UDP flows. As a consequence, parameters defined in
TDM Circuit Emulation Service over PSN November 2001
Section .7 MUST 6 should be added incorporated into to the appropriate service-specific service-
specific MIB module.
[RFC1889] defines a convention for associating an RTCP session with
each RTP/UDP/IP one. Possible usage of RTCP for CESoPSN is left for
further study.
A2. MPLS PSN
Note: The text below does not define a generic RTP/MPLS stack. Such
a work is clearly out of scope of this document.
TDM Circuit Emulation Service over PSN August 2002
This section is concerned with the case of MPLS being used as both
the Carrier PSN and Carrier Convergence multiplexing layer for the CESoPSN PW.
In this case, CESoPSN packet MUST be prepended with an MPLS label
stack including:
o A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This
entry acts as the PW demuxing field. multiplexing layer header. It MUST be
present in the stack and MUST be marked as residing at the
bottom of the stack
o A tunnel label entry. This label, if present, acts as the Carrier PSN
header and must immediately pressed precede the VC label entry. It MAY
be omitted in some situations.
This combination of Carrier layer PSN and PW demuxing technique multiplexing layers does not provide
either frame length information or ability to detect misconnections.
The former is not necessary for CESoPSN but limits ability to detect mis-connections.
malformed packets in case of a very short packet payload. The mis-connection
misconnection detection functionality can be provided using SSRC values the
following considerations:
1. The pattern in the first four bits following the bottom label
('1000') can be used as indication of an RTP
part header as it is
distinct from any of the CESoPSN header.
Since following:
a. IPv4 pattern ('0100')
b. IPv6 pattern ('0110')
c. Pattern produced by Layer 2 services over MPLS does nor allow to infer actual payload size, CESoPSN
ability encapsulated
in accordance with [MARTINI-ENCAP] and using control word
('0000')
2. The SSRC field of the RTP header can be further used to detect mis-type defects is limited.
misconnection.
MPLS tunnels are conventionally established using various signaling
protocols. As a consequence, parameters used for setup and teardown
of CESoPSN tunnels MUST should be mapped to data elements of these
protocols.
A3. L2TP PSN
Note: The text below does not define a generic RTP/L2TPv3 stack.
Such a work is clearly out of scope of this document.
CESoPSN packets may be carried in L2TPv3 tunnels over IP (see
[L2TPv3]).
[L2TPv3]) that would act as an alternative multiplexing layer over
IP.
Since L2TP L2TPv3 provides both data and control plane for tunnel
establishment, parameters describing payload and payload convergence encapsulation
layers SHOULD should be defined as AVPs to allow single-ended setup and
teardown of CESoPSN PWs.
L2TPv3 tunnels represent a PW demuxing technique multiplexing layer with an optional
ability to detect misconnections (using "cookies"). using 32-bit or 64-bit "cookies".
As a consequence,
SSRC-based misconnection detection by CESoPSN MAY be disabled. the PSN operator may choose between the L2TPv3-
TDM Circuit Emulation Service over PSN November 2001 August 2002
based and SSRC-based misconnection detection techniques for CESoPSN
PWs.
IP represents a Carrier PSN layer with inherent ability to infer the payload
size from the header. As a consequence, payload mistype malformed packets detection SHOULD take the
should consider actual payload size into consideration. size.
ANNEX B. EMULATION OF SONET/SDH CIRCUITS
B1. Relevant Types of SONET/SDH circuits
o OC-1
o OC-3
o OC-3c STS-1
o STM-1
B2. Native Frame Size and Payload Format
Since natural
Natural delineation of SONET/SDH frames (of abovementioned rates)
will produce packets exceeding minimal MTU in some cases, the
fragmentation of the cases. As a
consequence, a SONET/SDH frame must be fragmented into few several
CESoPSN packets will be used.
As an intentional contradiction to general principles stated in
[PWE3-FW], usage
Usage of CESoPSN for unstructured SONET/SDH circuits requires
presence of an appropriate framer in the ingress and egress PEs.
Each SONET/SDH frame will be fragmented into the Protocol Data Units
(PDUs) of equal size. Data belonging to two and more different
frames MUST NOT be combined into one PDU. For each SONET/SDH frame, frame
only one CESoPSN packet contains will contain the framing octets (A1. (A1, A2) of
this frame. Such a packet:
o MUST contain these bytes aligned with its payload data
(i.e., the 1st octet of the payload MUST contain the 1st A1
byte of a SONET/SDH frame
o SHOULD be marked with M bit set to 1 in the RTP header.
B3. Synchronization modes
The following techniques, described in [PWE3-FW] may be used for
defining "SONET/SDH as unstructured TDM" transmission clock.
o External timing
o Adaptive timing
o Differential (SRTS) timing
o RTP-based timing.
The applicability of these techniques may be defined as follows:
B3.1.
External and Differential Timing
The external clock sources traceable (in terms of G.781) to the same
high quality (at least as defined in G.812) clock source should be
available at both PEs for External and SRTS or Differential timing.
B3.2 Adaptive Timing
TDM Circuit Emulation Service over PSN November 2001
As mentioned in Section .5.2 above, adaptive timing seems sufficient
for SONET/SDH circuits if Stratum 3E clocks are available at each end
of a PW.
If the worst case of clock deviation (.20 ppm) is taken into account,
this method reduces in unacceptable increase of jitter buffer. Using
RTP-based clock recovery techniques in these situations may be
beneficial.
B.3. Structure of the Control Word
The same bits as defined in Section .6.2.2 5.2.2 are used. However the
meaning of the bits are slightly different:
o Bit A - if set, represents LOS (e.g., as specified in [G.783])
of the incoming SONET/SDH signal. A packet with the A bit set
should not carry any data
o Bit I - if set, represents an Out-of-Frame (OOF) condition
(e.g., as specified in [G.707]) of the incoming SONET/SDH
signal. A packet with the I bit set should not carry any data
TDM Circuit Emulation Service over PSN August 2002
B4. Packetization and de-packetization
During normal operation, the CESoPSN packetizer will receive a fixed
rate byte stream from a (physical or logical) SONET/SDH interface.
When the whole SONET/SDH frame will be received, it will be
partitioned into several blocks of equal size. After that, Carrier
Convergence PSN and Carrier
multiplexing headers are prepended to it and the resulting CESoPSN
packets are transmitted into the PSN.
Because all normal CESoPSN packets associated with a specific
SONET/SDH channel will have the same length, the transmission of
CESoPSN packets for that channel SHOULD occur at regular intervals.
At the far end of the packet network, the CESoPSN de-packetizer will
receive packets into a jitter buffer, rebuild native SONET/SDH
frames, and then play out the received byte stream at a fixed rate
onto the corresponding PDH channel. The jitter buffer SHOULD be
configurable to account for various network delay behavior patterns.
The receive received packet rate from the packet network should be exactly
balanced by the transmission rate onto the SONET/SDH channel, on
average. The time over which this average is taken corresponds to
the depth of the jitter buffer for a specific CESoPSN channel.
The RTP sequence numbers in the CESoPSN heard provide a mechanism to
detect lost and/or mis-ordered reordered packets. The CESoPSN de-packetizer
MUST detect lost or mis-ordered reordered packets. If any of the packets
carrying the any PDU of native
B6. PSN to SONET/SDH frame is lost or mis-
ordered, the Signals
Only CESoPSN de-packetizer MUST play out a scrambled pattern
consisting of valid framing bytes ([G.707], [T1.105]) and all other
bytes set to all 1s in place of this frame. defects requiring non-standard treatment are
considered.
The CESoPSN de-
packetizer de-packetizer MAY re-order packets received out of
order. If the
TDM Circuit Emulation Service over PSN November 2001 CESoPSN de-packetizer does not support re-ordering,
it MUST drop mis-
ordered out-of-order packets.
B5. Clock recovery issues.
Since "SONET/SDH as Unstructured TDM" application is a "trunking"
application, separate, independent clock signals per CESoPSN PW and
for each direction of CESoPSN are required.
B6. PSN to SONET/SDH Signals
The common CESoPSN fault precedence rules equally apply to CESoPSN
carrying unstructured SONET/SDH.
As a consequence, only defects requiring non-standard treatment are
considered.
B6.1. Loss of Packets
If any of the PDUs, PDUs comprising the a native SONET/SDH frame is lost, the
scrambled pattern consisting of valid framing bytes ([G.707],
[T1.105]) and all other bytes set to all 1s will be played out. The
same pattern will be played out if a malformed packet has been
detected.
The rationale for this behavior: an SDH node at the egress of a
CESoPSN service may continue using the SDH signal received from the
egress PE node as its clock source.
B6.2. Payload Mistype
The scrambled pattern consisting of valid framing bytes ([G.707],
[T1.105]) and all other bytes set to all 1s will be played out with
local clock available at this PW, until synchronization restoration.
B6.3. Loss of Synchronization
The scrambled pattern consisting of all bytes (including A1, A2) set
to all 1s will be played out with local clock available at this PW,
until synchronization restoration.
ANNEX C. A COMMON PW SETUP AND TEARDOWN MECHANISM
Note: Description of such a mechanism belongs to one of the more
generic PWE3 documents. It is presented here only to provide a
reference point for CESoPSN parameters defined in Section .7 and
presumably will be removed in the final release of the document.
C1. PW Setup
Two PW end services must exist before a PW is set up. Initially, each
of them is considered unbound to any PW and behaves as inactive
towards the appropriate CE (exact definition of inactivity is payload
layer-specific).
TDM Circuit Emulation Service over PSN November 2001
The PW setup is controlled by the common PW layer that implements the
following logic:
1. PW setup is initiated by an external command. This command can
be initiated either by the management system or by the L1/L2
VPN auto-discovery process (e.g., see [KOMPELLA]) etc. and
carries the following parameters:
a. Identification of PEs terminating each of the two end
services to be connected by a PW. Router ID of PE SHOULD
be used for this purpose
b. Local, within each PE, identification of each of the end
services to be connected by a prospective PW. In most
cases, ifIndex of the end service MAY be used for this
purpose
c. PW Type. This parameter MUST uniquely identify the
combination of payload and payload convergence layers to
be used with the prospective PW
d. Payload-specific parameters of each of the end services
e. Payload convergence layer-specific parameters defining
behavior of this layer
f. For L1 (Circuit) PWs - common PW layer parameters
g. Optionally (if the carrier layer is Diffserv-enabled) -
identification of the PHB that should be implemented by
the PSN for providing desired quality of the PW
emulation. PHB Identification Codes (see [RFC3140]) MUST
be used for this purpose
2. The Common PW layer:
a. Verifies that the specified end services are not bound to
any PW yet
b. Requests path MTU between the specified pair of PE
devices from the Carrier Layer
c. Uses services of the payload layer to verify that the end
service parameters and PW type are compatible
d. In case of L1 (Circuit) PWs verifies that the number of
payload bytes defined in the request is compatible with
the Path MTU provided by the Carrier Layer
e. Uses identification of the pair of PEs and relative
identification of ESs within each PE in order to create
common PW headers. This includes allocation of PW
demuxing fields in these headers
f. Passes PE identification and desired PHBID to the Carrier
layer and obtains appropriate Carrier headers
3. Failure of any of the above-mentioned operations MUST result
in:
a. Release of all already allocated resources (if any)
b. Indication of a PW setup failure response to the
originator of the external command
4. Once all the operations mentioned above has been successfully
completed, the common PW layer:
a. Binds the end services to the newly created PW so that
they become PW end services
TDM Circuit Emulation Service over PSN November 2001
b. Passes Common PW, Carrier and Carrier Convergence headers
to the IWF functions (in the Payload Conversion layer) at
both ends of the PW and signals them to start operation
c. Sends a PW setup success response to the originator of
the external command
5. Each of the IWF functions at both ends of the PW, upon
receiving this signal:
a. Signals the payload layer for activation of the
respective end service towards its CE
b. Starts its operation in inbound and outbound directions
C2. PW Teardown
1. The PW tear-down can be initiated by:
a. An external command
b. A signal from the peer indicating that the PW demuxing
field used by the PW is no longer valid
c. A signal from the Carrier layer indicating that the
Carrier header used by the PW is no longer valid
2. In any case the PW common layer, upon receiving such a
command:
a. Signals the IWF functions at both ends of the PW to stop
operation. In their turn, these signal the payload layer
for deactivation of their respective end services towards
CE
b. Releases all the resources allocated to this service
(including PW demuxing field values)
c. Unbinds end services from the PW
d. If necessary, sends a response to originator of the PW
teardown command.
TDM Circuit Emulation Service over PSN November 2001
ANNEX D. COMPARISON OF DIFFERENT APPROACHES
Note: This annex will be removed from the final document.
The following techniques for carrying PDH traffic over PSN are
compared:
1. TDMoIP as described in [ANAVI-TDM]
2. CESoP as defined in [PATE-TDM]
3. CESoPSN as defined in this document.
Criteria and results of evaluation are presented below. All the
results refer to the latest available releases of the documents.
1. Supported Services
a. Unstructured E1/T1 - supported by TDMoIP, CEoP and CESoPSN
b. Fractional E1/T1 - supported in TDMoIP and CESoPSN, not
supported in CEoP
c. Fractional E1/T1 with CAS - supported by TDMoIP, left FFS
by CESoPSN, not supported by CEoP
d. Unstructured E3/T3 - supported by TDMoIP, CESoPSN and CEoP
(by reference to [MALIS-SONET])
e. The following "bundling" services are supported only by
CEoP
i. TUG2/VTG - supported only by CEoP
ii. Fractional STS-1/STM-0 - supported only by CEoP
f. Unstructured STS-3c/STM-1 is supported only by CESoPSN
2. Basic approach:
a. TDMoIP is AAL1 or AAL2-based with the packet payload
internally subdivided into 47-byte "cells"
b. CEoP uses standard mapping of PDH data streams into SONET
VT/SDH low-order VC
c. CESoPSN uses raw TDM data packetization that preserves
native circuit delineation and, for structured services,
alignment of the circuit structure with the packet
3. Synchronization models and dependency upon availability of
network-wide central clock:
a. TDMoIP preferably uses network-wide central clock, but can
also use adaptive and RTP-based techniques
b. CEoP requires Stratum 3 (or better) network-wide central
clock and uses SONET/SDH pointer justification
c. CESoPSN uses RTP-based synchronization by default.
(Optionally, adaptive synchronization or network-wide
central clock can be used)
4. Relevant PSN types and demuxing techniques:
a. TDMoIP requires UDP/IP (some bits in the UDP source port
field are used to distinguish between packets with and
without RTP header)
b. CEoP and CESoPSN are invariant to the PSN type (IP or MPLS)
c. CEoP uses MPLS for PW demuxing
d. CESoPSN is invariant to the demuxing technique
5. Packetization delay and PW Switching Rate:
TDM Circuit Emulation Service over PSN November 2001
a. Configurable for TDMoIP and CESoPSN
b. Limited configuration capabilities (packetization delay <=
0.5 ms, PW switching rate >= 2000 pps) for CEoP
6. Basic Encapsulation efficiency:
a. Unstructured E1:
i. TDMoIP - depends on packetization delay. For 1 ms
delay - 3.7% overhead without RTP, 8.4% with RTP
ii. CEoP - cannot be improved over 12.5%
iii. CESoPSN - depends on packetization delay. For 1 ms
delay - 6.25% overhead
b. Unstructured T1:
i. TDMoIP - depends on packetization delay. For 1 ms
delay - 4.2% overhead without RTP, 10.4% with RTP
ii. CEoP - cannot be improved over 11.9%
iii. CESoPSN - depends on packetization delay. For 1 ms
delay - 11.9% overhead
c. Unstructured E3:
i. Not evaluated for TDMoIP
ii. More than 47% overhead for CEoP
iii. Depends on packetization delay. For 125 us
packetization delay - 3% overhead
d. Unstructured T3:
i. Not evaluated for TDMoIP
ii. More than 12% overhead for CEoP
iii. Depends on packetization delay. For 125 us
packetization delay - 2.3% overhead
7. OAM Capabilities:
a. One type of defect (LOPS)defined for CeoP
b. Lost packets are signaled from egress to ingress TDMoIP
c. Multiple defects and their hierarchy defined for CESoPSN as
well as loopback capabilities
8. Dynamic Bandwidth Allocation (DBA) Capabilities:
a. Not defined for TDMoIP
b. Wrong type of DBA defined for CEoP (based on SONET/SDH AIS
and Unequipped indications instead of condition of the
payload)
c. Based on payload state indications (AIS, Idle Code) for
CESoPSN