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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/