Network Working Group A. Vainshtein - Editor (Axerra Networks)
Internet Draft I. Sasson (Axerra Networks)
A. Sadovski (Axerra Networks)
Expiration Date: E. Metz (Thrupoint)
December 2003 T. Frost (Zarlink Semiconductor)
P. Pate (Overture Networks)
June 2003
TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)
draft-vainshtein-cesopsn-06.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a method for encapsulating unstructured (T1,
E1, T3, E3) and structured (Nx64 kbit/s) TDM signals as pseudo-wires
over packet-switching networks (PSN). In this regard, it complements
similar work for SONET/SDH.
Proposed PW encapsulation uses RTP for clock recovery and leverages
RTP-based mixing capabilities for application state signaling between
Customer Edge (CE) devices.
TABLE OF CONTENTS
1. Introduction......................................................3
2. Summary of Changes from the -05 Revision..........................3
3. Terminology and Reference Models..................................4
3.1. Terminology...................................................4
3.2. Reference Models..............................................5
3.2.1. Generic Models............................................5
3.2.2. Synchronization Considerations and Deployment Scenarios...5
3.2.3. Generic and Specific Requirements.........................5
3.2.4. Non-Requirements..........................................6
Vainshtein et al. [Page 1]
TDM Circuit Emulation Service over PSN June 2003
4. Scope.............................................................7
4.1. Emulated Services.............................................7
4.1.1. Unstructured services.....................................7
4.1.2. Structured services.......................................7
4.2. Affected Protocol Layers......................................8
5. CESoPSN Encapsulation Layer.......................................9
5.1. CESoPSN Packet Format.........................................9
5.2. PSN and Multiplexing Layer Headers............................9
5.3. Optional "ECMP Prevention" Word...............................9
5.4. CESoPSN Header................................................9
5.4.1. Usage of RTP Header......................................10
5.4.2. Usage and Structure of the Control Word..................11
6. CESoPSN Payload Layer............................................12
6.1. Common Payload Format Considerations.........................12
6.2. Payload Format for Structured Services.......................13
6.2.1. Common Considerations....................................13
6.2.2. Basic Nx64 kbit/s Services...............................13
6.2.3. Trunk-Specific Nx64 kbit/s Services with CAS.............15
6.3. Unstructured Services........................................18
6.3.1. Basic Payload Format.....................................18
6.3.2. Octet-aligned T1 Service.................................18
7. CESoPSN Operation................................................18
7.1. Common Considerations........................................18
7.2. End Service Inactivity Behavior..............................19
7.3. Description of the IWF operation.............................19
7.3.1. PSN-bound Direction......................................19
7.3.2. CE-bound Direction.......................................20
7.4. CESoPSN Defects..............................................21
7.4.1. Misconnection............................................21
7.4.2. Re-Ordering and Loss of Packets..........................21
7.4.3. Malformed Packets........................................22
7.4.4. Jitter Buffer Overrun....................................23
7.4.5. Remote Loss of Packet Synchronization....................23
7.5. Performance Monitoring.......................................24
7.5.1. Errored Data Blocks......................................24
7.5.2. Errored, Severely Errored and Unavailable Seconds........24
8. QoS Issues.......................................................24
9. RTP Payload Format Considerations................................24
9.1. Resilience to moderate loss of individual packets............24
9.2. Ability to interpret every single packet.....................25
9.3. Non-usage of the RTP Header Extensions.......................25
9.4. Compression of RTP headers...................................25
10. Congestion Control (RFC 2914) Conformance.......................26
11. FFS Issues......................................................26
12. Security Considerations.........................................26
13. Applicability Statement.........................................27
14. IANA Considerations.............................................28
15. Intellectual Property Disclaimer................................28
ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM..........32
Annex B. Reference PE Architecture for Emulation of NX64 kbit/s
SERvices............................................................34
Annex C. Payload and Encapsulation Layer Parameters.................36
Vainshtein et al. Expires December 2003 [Page 2]
TDM Circuit Emulation Service over PSN June 2003
1. Introduction
This document describes a method for encapsulating unstructured (T1,
E1, T3, E3) and structured (Nx64 kbit/s) TDM signals as pseudo-wires
over packet-switching networks (PSN). In this regard, it complements
similar work for SONET/SDH (see [PWE3-SONET]).
To support emulation of TDM traffic, which includes leased line, voice
and data services, it is necessary to emulate the circuit
characteristics of a TDM network. A circuit emulation header and RTP-
based mechanisms for carrying the clock over PSN are used to
encapsulate TDM signals and provide the Circuit Emulation Service over
PSN (CESoPSN).
Ability to carry unstructured TDM traffic best suits the leased line
applications.
Ability to emulate Nx64 kbit/s circuits provides for saving PSN
bandwidth, supports DS0-level grooming and distributed cross-connect
applications. It also enhances resilience of CE devices to effects of
loss of packets in the PSN.
The CESoPSN solution presented in this document fits the PWE3
architecture described in [PWE3-ARCH] and satisfies the general
requirements put forward in [PWE3-REQ].
2. Summary of Changes from the -05 Revision
Note: This section will be removed from the final document.
1. Nx64 kbit/s services with N exceeding the number of timeslots
in a single E1 or T1 trunk are introduced
2. Insertion of an optional 32-bit word with the zeroed first
nibble between the bottom label of the label stack and the
CESoPSN header (including or not including the fixed RTP
header) has been defined. Using this word prevents false
recognition of CESoPSN packets as IPv4 or IPv6 packets by core
routers implementing proprietary ECMP techniques in an MPLS-
enabled IP network
3. The method for carrying trunk-specific Nx64 kbit/s with CAS
has been specified
4. Format of the CESoPSN control word has been fully aligned with
that defined in [PWE3-SONET]. As part of the alignment, the
structure pointer (introduced in the previous revision) has
been compressed to a single bit.
Vainshtein et al. Expires December 2003 [Page 3]
TDM Circuit Emulation Service over PSN June 2003
3. Terminology and Reference Models
3.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms defined in [PWE3-ARCH], Section 1.4 are consistently used
without additional explanations.
This document uses some terms and acronyms that are commonly used in
conjunction with the TDM services. In particular:
o Frame Alignment Signal (FAS) is a common term denoting a
special periodic pattern that is used to impose synchronous
structures on E1, T1, E3 and T3 circuits. Actual FAS patterns
are described in [G.704] and [G.751]
o Out of Frame Synchronization (OOF) is a common term denoting
the state of the receiver of a TDM signal when it failed to
find valid FAS. Actual conditions for declaring and clearing
OOF are described in [G.706]
o Alarm Indication Signal (AIS) is a common term denoting a
special bit pattern in the TDM bit stream that indicates
presence of an upstream circuit outage. Actual methods for
detecting the AIS condition in a TDM stream are defined in
[G.775]
o Remote Alarm Indication (RAI) is a common term denoting a
special pattern in the framing of a TDM service that is sent
back by the receiver that experiences an AIS condition
o Channel-Associated Signaling (CAS) is a common term describing
one of the methods of exchanging signals between telephony
applications. CAS is based on allocation of up to 4 constant-
rate synchronous bit-streams for each Voice-carrying DS0
channel in an E1 or T1 trunk. These bit-streams are commonly
denoted A, B, C and D. The actual methods of carrying the sets
of these bit streams isochronously in an E1 or T1 trunk and
establishing association between a specific DS0 channel with
an appropriate set of these bit streams are described in
[G.704].
Note: CAS can be interpreted in two different ways. A "synchronous"
interpretation treats it as a set of bit-streams, while a "signaling"
interpretation treats it as a method to encode signals reflecting
change of state of telephony applications based upon generation and
detection of certain stable bit patterns in the CAS-related bit-
streams. The most commonly used patterns include "stable ones" and
"stable zeroes"; (i.e., two states per bit-stream); in some cases they
are augmented by a "stable alternate pattern" (providing the 3rd state
of the bit-stream). The combination of these patterns allows encoding
of up to 16 different telephony application states. Most modern E1 and
T1 framers support both approaches by providing:
Vainshtein et al. Expires December 2003 [Page 4]
TDM Circuit Emulation Service over PSN June 2003
1. For the synchronous approach - dedicated pins that allow
extraction/insertion of the relevant constant-rate bit-streams
into appropriate positions in the E1 or T1 trunk
2. For the signaling approach:
a) Dedicated memory-mapped registers which allow reading the
actual stabilized CAS bits values/writing the desired
combination of CAS bits values
b) Generation of interrupts when a de-bounced change of CAS
bits has been detected.
Note: Another method of exchanging signals between telephony
applications is called Common Channel Signaling (CCS). This method is
not considered in this document.
3.2. Reference Models
3.2.1. Generic Models
Generic models that have been defined in Sections 4.1, 4.2 and 4.4 of
[PWE3-ARCH] are fully applicable for the purposes of this document
without any modifications.
Unstructured services considered in this document represent special
cases of the bit stream payload type defined in Section 3.3.3 of [PWE3-
ARCH].
Structured services considered in this document represent special cases
of the structured bit stream payload type defined in Section 3.3.4 of
[PWE3-ARCH]. In each specific case the basic service structures that
are carried by a CESoPSN PW across the PSN are explicitly specified
(see below).
3.2.2. Synchronization Considerations and Deployment Scenarios
The Network Synchronization reference model and deployment scenarios
for emulation of TDM services have been described in [PWE3-TDM-REQ],
Section 4.2.
3.2.3. Generic and Specific Requirements
The protocol defined in this document has been designed in order to
satisfy the requirements presented in [PWE3-REQ] and [PWE3-TDM-REQ].
In addition it places a strong emphasis on emulation of end-to-end
delay characteristics of TDM networks. These networks are built using
"fixed delay" increments and for this purpose consistently use 125
microseconds' frames at all the levels of hierarchy. Among other
things, this approach guarantees the same end-to-end delay for all the
channels carried between any two given points in the network. Faithful
emulation of TDM networks cannot ignore these properties because they
Vainshtein et al. Expires December 2003 [Page 5]
TDM Circuit Emulation Service over PSN June 2003
form an important part of the overall network design that, generally,
speaking, includes both the "native TDM" segments and the "TDM PW"
segments comprising a single end-to-end emulated service that is
subject to delay budget restrictions.
Edge-to-edge delay for PWs carrying TDM services is defined by the
following factors:
1. The PSN transport delay between the given pair of PEs
2. The delay required for compensation of the packet delay
variation (PDV) between the given pair of PEs.
3. The packetization latency (i.e. the time required to fill a
single TDM PW packet with the TDM data).
The first two factors are essentially out of control of the PWE3
protocol designer. This leaves only the packetization latency to play
with.
The CESoPSN protocol has been designed in order to satisfy the
following requirements:
1. Fixed amount of TDM data per packet: All the packets belonging
to a given CESoPSN PW MUST carry the same amount of TDM data.
This requirement:
a) Allows enhanced detection of lost packets
b) Simplifies compensation of a lost PW packet with a packet
carrying exactly the same amount of "replacement" data
2. Fixed end-to-end delay: CESoPSN implementations SHOULD provide
the same end-to-end delay between any given pair of PEs
regardless of the bit-rate of the emulated service.
3. Packetization latency range:
a) All the implementations of CESoPSN SHOULD support
packetization latencies in the range 1 to 3 milliseconds
b) CESoPSN implementations that support configurable
packetization latency:
i. MUST allow configuration of this parameter with the
granularity which is a multiple of 125 microseconds
ii. SHOULD allow configuration of this parameter with the
resolution of 1 millisecond.
4. Exceptions to requirements 3.a) and 3.b) ii. above can be
considered, e.g., when:
a) The required packet size (or increment/decrement to this
size) exceeds reasonable Path MTU expectations due to high
bit-rate of the emulated service. This consideration
justifies lower packetization latencies and lower
granularity of configuration
b) The BW effectiveness of the resulting PW is unreasonably
low due to low bit-rate of the emulated service. This
consideration justifies higher packetization latencies.
3.2.4. Non-Requirements
The following items are considered as non-requirements for CESoPSN:
Vainshtein et al. Expires December 2003 [Page 6]
TDM Circuit Emulation Service over PSN June 2003
1. Perfect emulation of TDM circuits.
2. "Preferential" treatment of any specific method of carrying
attachment circuits between CE and PE
3. Ability to upgrade devices providing emulation of TDM circuits
over ATM networks (see [ATM-CES]) to devices providing emulation
of TDM circuits over PSN.
4. Scope
4.1. Emulated Services
This specification describes service-specific encapsulation layer for
edge-to-edge emulation of the following TDM services:
4.1.1. Unstructured services
CESoPSN supports edge-to-edge emulation of the following unstructured
TDM services:
1. E1 (2048 kbit/s) as described in [G.702]
2. T1 (1544 kbit/s) as described in [G.702]. This service is also
called DS1
3. E3 (34368 kbit/s) as described in [G.751]
4. T3 (44736 kbit/s) as described in [G.702]. This service is
also known as DS3
All the unstructured TDM services discussed in this document represent
specific cases of the generic bit stream payload type defined in [PWE3-
ARCH].
The protocol used for emulation of these services does not depend on
the physical format of the attachment circuits at both ends of the PW.
All CESoPSN implementations MUST support appropriate unstructured
services. E.g., implementation that supports E1 attachment circuits,
MUST support emulation of unstructured E1 etc.
4.1.2. Structured services.
Structured TDM services are usually carried within appropriate physical
trunks, and PEs providing their emulation usually include appropriate
Native Service Processing (NSP) blocks commonly referred to as Framers.
The NSP may also act as a digital cross-connect, creating structured
TDM services from multiple synchronous trunks. As a consequence, the
service may contain more timeslots that could be carried over any
single trunk.
The only type of structured services considered in this specification
is Nx64 kbit/s with and without CAS. This service belongs to the
generic structured bit-stream payload type as defined in [PWE3-ARCH],
and reference PE architecture supporting such services is described in
Annex B.
Vainshtein et al. Expires December 2003 [Page 7]
TDM Circuit Emulation Service over PSN June 2003
The taxonomy of Nx64 kbit/s services defined in [ATM-CES] provides the
following set of services:
1. Basic Nx64 kbit/s service:
a) The structure ("frame") associated with this service that
MUST be preserved in edge-to-edge emulation is an array of
N octets, where the all the octets belong to the same frame
of the "trunk" E1 or T1 circuit (in case of a service
created by the NSP acting as a digital cross-connect from
several synchronous E1 or T1 trunks, all the octets belong
to the frame defined by the common frame clock pulse of
these services), and i-th octet contains the data of the i-
th DS0 channel (timeslot) in the bundle. The circuit
generates 8000 frames per second
b) This service can be optionally extended to support CAS by
employing the "signaling" interpretation of CAS and
carrying CE application signals in dedicated signaling
packets
c) Implementations MUST support N <=31 and MAY optionally
support larger values of N
2. "Trunk-specific" Nx64 kbit/s service with CAS. The definition
of these services employs "synchronous" interpretation of CAS,
and the structures that must be preserved by the PW are trunk
multiframes. Signaling information is carried appended to TDM
data in the "signaling sub-structures" defines in [ATM-CES].
Since the number and bit rates of CAS bit-streams depend on
the specific framing method used with an E1 or T1 trunk, the
following services are considered:
a) E1-Nx64 kbit/s service with CAS, 1 <= n <= 30
b) T1/ESF-Nx64 kbit/s service with CAS, 1 <= n <= 24
c) T1/SF-Nx64 kbit/s service with CAS, 1 <= n <= 24.
Note: For T1 trunks using SF format (12 frames per multiframe), CESoPSN
preserves the structure comprising two consecutive trunk multiframes.
This consideration is aligned with [ATM-CES].
Note: As mentioned above, Nx64 kbit/s services can be formed by NSP
blocks form timeslots belonging to several synchronous E1 or T1 trunks.
In this case NSP acts as a digital cross-connect and provides a common
frame clock for these services, and the resulting "frames" (i.e.,
arrays of N octets, one from each DS0 in the Nx64 kbit/s bundle and all
sampled at the same frame clock signal, act as the basic structures to
be preserved for emulation of basic Nx64 kbit/s services.
Support of all the structured TDM services is OPTIONAL.
4.2. Affected Protocol Layers
This specification defines the encapsulation layer and payload format
for edge-to-edge emulation of unstructured (T1, E1, T3, E3) and
structured (Nx64 kbit/s) TDM services.
Vainshtein et al. Expires December 2003 [Page 8]
TDM Circuit Emulation Service over PSN June 2003
In accordance with the principle of minimum intervention ([PWE3-ARCH],
Section 3.3.5) the TDM payload is encapsulated without any changes.
5. CESoPSN Encapsulation Layer
5.1. CESoPSN Packet Format
The basic format of CESoPSN packets is shown in Fig. 1 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN and multiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|0 0 0 0 Reserved (OPTIONAL - only for an MPLS-enabled IP PSN) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Fixed |
+-- --+
| RTP |
+-- --+
| Header (see [RFC1889]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Packetized TDM data (Payload) |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Basic CESoPSN Data Packet Format
5.2. PSN and Multiplexing Layer Headers
The total size of a CESoPSN packet for a specific PW MUST NOT exceed
path MTU between the pair of PEs terminating this PW. CESoPSN
implementations working with IPv4 PSN SHOULD set the "Don't Fragment"
flag in IP headers of the packets they generate.
5.3. Optional "ECMP Prevention" Word
If the PSN providing connectivity between the PE devices is an MPLS-
enabled IP network that employs proprietary Equal Cost Multiple Path
(ECMP) load-balancing mechanisms, CESoPSN implementations SHOULD allow
insertion of a 32-bit word with zeroed first nibble between the bottom
label of the label stack and the RTP header. Such an arrangement
guarantees that CESoPSN packets would be never be misinterpreted as
IPv4 or IPv6 packets by ECMP algorithms in the core LSRs. However, the
egress PE MUST NOT interpret the contents of this word in any way.
5.4. CESoPSN Header
Vainshtein et al. Expires December 2003 [Page 9]
TDM Circuit Emulation Service over PSN June 2003
The CESoPSN header comprises a fixed RTP header (12 octets) and a
CESoPSN Control Word (4 octets).
Note: Under certain circumstances the RTP header MAY be suppressed in
order to conserve network bandwidth. See section 9.4 for details. If
RTP header is not suppressed, the risk of CESoPSN packets aliasing IPv4
or IPv6 packets carried over the same LSP in an MPLS-enabled IP network
is minimal (see below).
5.4.1. Usage of RTP Header
CESoPSN uses the fields of the fixed RTP header (see [RFC1889], Section 5.1) in the following way:
1. V (version) is always set to 2
2. P (padding) is always set to 0
3. X (header extension) is always set to 0
4. CC (CSRC count) is always set to 0
5. M (marker) is set to 0
6. PT (payload type) are used as following:
a) One PT value MUST be allocated from the range of dynamic
values (see [RTP-TYPES]) for each direction of the PW. The
same PT value MAY be reused for both directions of the PW
and also reused between different PWs
b) The PE at the PW ingress MUST set the PT field in the RTP
header to the allocated value
c) The PE at the PW egress MAY use the received value to
detect malformed packets
7. Sequence number is used primarily to provide the common PW
sequencing function as well as detection of lost packets. It
is generated and processed in accordance with the rules
established in [RFC1889]
8. Timestamps are used primarily for carrying timing information
over the network:
a) Their values are generated in accordance with the rules
established in [RFC1889]
b) Frequency of the clock used for generating timestamps MUST
be an integer multiple of 8 kHz. All implementations of
CESoPSN MUST support the 8 kHz clock. Other frequencies
that are integer multiples of 8 kHz MAY be used if both
sides agree to that
c) Possible modes of timestamp generation are discussed below
9. The SSRC (synchronization source) value in the RTP header MAY
be used for detection of misconnections.
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 timestamps using the clock
recovered from the incoming TDM circuit. As a consequence, the
timestamps are closely correlated with the sequence numbers.
All CESoPSN implementations MUST support this mode
Vainshtein et al. Expires December 2003 [Page 10]
TDM Circuit Emulation Service over PSN June 2003
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. As a
consequence, the second derivative of the timestamp series
represents the difference between the common timing source and
the clock of the incoming TDM circuit. Support of this mode is
OPTIONAL.
Usage of other timestamp generation modes is left for further study.
Note: Differential mode of timestamp generation MAY be used for SRTS-
like clock recovery.
5.4.2. Usage and Structure of the Control Word
Usage of the CESoPSN control word allows:
1. Differentiation between the PSN problems and the problems
beyond the PSN as causes for the emulated service outages
2. Saving bandwidth by not transferring invalid data (AIS, idle
code)
3. Signaling problems detected at the PW egress to its ingress
4. Decoupling packet payload size from the size of the structures
in case of structured emulation.
The structure of the CESoPSN Control Word is shown in Fig. 2 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|R|D|N|P|S| Reserved (12 bits) | Optional sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Structure of the CESoPSN Control Word
o Bit E - if set, indicates presence of an extended control
word. Extensions of the control word are not defined in this
specification, hence currently this bit MUST be always set to
0
o Bit R - if set, carries Remote indication of Loss of Packet
Synchronization (see below)
o Bits D, N and P encode various conditions of the incoming TDM
Attachment Circuit as shown in Table 1 below. Packets with the
bit D set MAY carry no payload
o Bit S - if cleared, indicates (for the structured services)
that the packet payload contains the start of at least one
basic structure, and in this case, the start of the first
basis structure in the packet MUST be aligned with the
beginning of the packet payload. If set - indicates that the
packet payload does not contain the start of any basic
structure. Bits S MUST be cleared for unstructured services
o Reserved bits (6 to 27) - SHOULD all be set to the same value
as bit S at ingress and MUST be ignored at egress
Vainshtein et al. Expires December 2003 [Page 11]
TDM Circuit Emulation Service over PSN June 2003
o Optional sequence number - implementation MAY copy 14 least
significant bits of the RTP sequence number into this field.
Otherwise it SHOULD be set to 0 at ingress.
+---+---+---+-----------------------+
| D | N | P | Interpretation |
+---+---+---+-----------------------+
| 0 | 0 | 0 | Normal Condition |
| 0 | 0 | 1 | Reserved |
| 0 | 1 | 0 | Reserved |
| 0 | 1 | 1 | RAI in the incoming AC|
| | | | |
| 1 | 0 | 0 | Idle code indication |
| 1 | 0 | 1 | Reserved |
| 1 | 1 | 0 | Reserved |
| 1 | 1 | 1 | AIS |
+---+---+---+-----------------------+
Table 1. Encoding of status of the TDM Attachment Circuit
Notes:
o The structure of the CESoPSN control word is aligned with that
defined in [PWE3-SONET]. The proposed usage of the S bit
matches with the definition of the value 0x1fff as an INVALID
structure pointer indication since the packet payload size for
CESoPSN does not exceed 4K octets (see below)
o For Nx64 kbit/s services, D, N and P bits are set or cleared
in accordance with the status of the AC detected by the
Framer. For unstructured E1, T1 and E3 services, the Line
Interface Unit (LIU) can detect the AIS condition ("all
ones"). Detection of the RAI condition for all types of
services as well as detection of the AIS condition for the T3
service requires operation of an appropriate Framer in the
"transparent" mode.
6. CESoPSN Payload Layer
6.1. Common Payload Format Considerations
CESoPSN always uses the so-called "Telecom" ordering, i.e.:
o The order of the payload octets corresponds to their order on
the PWES line
o Consecutive bits coming from the PWES line fill each payload
octet starting from its most significant bit to the least
significant one.
All the CESoPSN packets MUST carry the same amount of valid TDM data in
both directions of the PW. In other words, the time that is required to
fill a CESoPSN packet with the TDM data must be constant. The PE
devices terminating a CESoPSN PW MUST agree on the number of TDM
payload octets in the PW packets for both directions of the PW at the
time of the PW setup.
Vainshtein et al. Expires December 2003 [Page 12]
TDM Circuit Emulation Service over PSN June 2003
Notes:
1. CESoPSN packets MAY omit invalid TDM data in order to save the
PSN BW. If the CESoPSN packet payload is omitted, the D bit in
the CESoPSN control word MUST be set
2. CESoPSN PWs MAY carry CE signaling information either in
separate packets or appended to packets carrying valid TDM
data. If signaling information and valid TDM data are carried
in the same CESoPSN packet, the amount of the former (agreed
between the pair of PE devices) does not affect the amount of
the latter.
6.2. Payload Format for Structured Services
6.2.1. Common Considerations
All the structured services are considered in this document are treated
as sequences of "basic structures" (see Section 4.1 above). The payload
of a CESoPSN packet always consists of a fixed number of octets filled,
octet by octet, with the data contained in the corresponding consequent
basic structures preserving octet alignment between these structures
and the packet payload boundaries.
The packet payload size for CESoPSN PWs for structures services MUST
NOT exceed 4K octets.
CESoPSN MUST use alignment of the basic structures with the packet
payload boundaries in order to carry the structures across the PSN.
This means that:
1. The amount of TDM data in a CESoPSN packet SHOULD be either an
integer multiple or an integer divisor of the structure size
2. If the amount of TDM data in a CESoPSN packet is an integer
multiple of the structure size, the first structure in the
packet SHOULD start immediately at the beginning of the packet
payload
3. If the amount of TDM data in a CESoPSN packet is an integer
divisor of the structure size, the structure should start
immediately at the beginning of the packet payload in all the
packets that contain the first octet of some structure. The
packets that do not contain the first octet of any basic
structure, should be marked by setting S bit to 0 in the
CESoPSN control word.
This mode of operation complies with the recommendation in [PWE3-ARCH]
to use similar encapsulations for structured bit stream and cell
generic payload types.
6.2.2. Basic Nx64 kbit/s Services
As mentioned above, the structure preserved across the PSN for this
service consists of n octets filled with the data of the corresponding
DS0 channels belonging to the same frame of the originating trunk(s),
and the service generates 8000 such structures per second.
Vainshtein et al. Expires December 2003 [Page 13]
TDM Circuit Emulation Service over PSN June 2003
Packetization latency, number of timeslots and payload size are linked
by the following obvious relationship:
L = 8*n*D
where:
o D is packetization latency, milliseconds
o L is packet payload size, octets
o n is number of DS0 channels.
CESoPSN implementations supporting Nx64 kbit/s services MUST support
the following set of configurable packetization latency values:
o For n >= 4: 1, 2 and 3 milliseconds (with the corresponding
packet payload size of 8*n, 16*n and 24*n octets respectively)
o For 1 <= n <= 3: 5 milliseconds (with the corresponding packet
payload size of 40*n octets).
Usage of any other packetization latency (packet payload size) that is
compatible with the restrictions given in Section 6.2.1 above is
OPTIONAL.
Implementations that have chosen to extend this service to support also
CAS carry encoded CE application state in separate signaling packets.
In order to do that, they MUST allocate an additional RTP payload type
(from the range of dynamically allocated types) for the signaling
packets. In addition, the signaling packets use their own SSRC value
(different from that used for the TDM data packets) and their own
sequence numbers.
Format of the signaling packets is shown in Fig. 3 below.
Received signaling packets are played out after synchronization with
the TDM data. The synchronization uses the standard RT-based mixing
procedures (see [RFC1889]).
Vainshtein et al. Expires December 2003 [Page 14]
TDM Circuit Emulation Service over PSN June 2003
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN and multiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Fixed |
+-- --+
| RTP |
+-- --+
| Header (see [RFC1889]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Encoded CE application state entry for the DS0 channel #1 |
+-- --+
| ... |
+-- --+
| Encoded CE application state entry for the DS0 channel #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. CESoPSN Signaling Packet Format
CE application state is represented by the current value of CAS bits
for the DS0 channel and is encoded in accordance with the rules
presented in [RFC2833]. Details of the protocol are discussed in Annex
A.
Note: The same protocol can be used in conjunction with other signaling
methods using appropriate format of signaling packets.
6.2.3. Trunk-Specific Nx64 kbit/s Services with CAS
As mentioned above, the structure preserved by CESoPSN for this group
of services is the trunk multiframe, and signaling information is
carried appended to the TDM data using the signaling substructures
defined it [ATM-CES]. These substructures comprise N consecutive
nibbles, so that the i-th nibble carries CAS bits for the i-th DS0
channel, and are padded with a dummy nibble for odd values of N.
CESoPSN implementations supporting trunk-specific Nx64 kbit/s services
with CAS MUST NOT carry more TDM data per packet than is contained in a
single trunk multiframe. The signaling substructures MUST be appended
to each CESoPSN packet with the cleared S bit in the CESoPSN control
word.
All CESoPSN implementations supporting trunk-specific Nx64 kbit/s with
CAS MUST support the default mode where a single CESoPSN packet carries
exactly one trunk multiframe aligned with the packet payload. In this
case:
1. Packetization latency is:
a) 2 milliseconds for E1 Nx64 kbit/s
b) 3 milliseconds for T1 Nx64 kbit/s
2. The packet payload size is:
Vainshtein et al. Expires December 2003 [Page 15]
TDM Circuit Emulation Service over PSN June 2003
a) 16*n + floor((n+1)/2) for E1-Nx64 kbit/s
b) 24*n + floor((n+1)/2) for T1/ESF-Nx64 kbit/s and T1/SF-Nx64
kbit/s
3. The packet payload format coincides with the "superframe
structure with signaling" defined in [ATM-CES].
In order to provide lower packetization latency, CESoPSN
implementations for trunk-specific Nx64 kbit/s with CAS SHOULD support
the TDM data payload sizes that satisfy the following conditions:
1. The amount of the TDM data per packet is an integer multiple
of N.
2. The amount of the TDM data per packet is a divisor of the
number of octets in the appropriate trunk multiframe, i.e.:
a) 16*N for E1-Nx64 kbit/s with CAS
b) 24*N for T1/ESF-Nx64 kbit/s with CAS and T1/SF-Nx64 kbit/s
with CAS.
Format of CESoPSN packets that do and do not contain signaling
substructures is shown in Fig. 4 (a) and (b) respectively.
Vainshtein et al. Expires December 2003 [Page 16]
TDM Circuit Emulation Service over PSN June 2003
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
--- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | | Timeslot 2 |
Frame #1 | ... | | ... |
| Timeslot n | | Timeslot n |
--- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | | Timeslot 2 |
Frame #2 | ... | | ... |
| Timeslot n | | Timeslot n |
--- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
... | ... | | ... |
--- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | | Timeslot 2 |
Frame #m | ... | | ... |
| Timeslot n | | Timeslot n |
--- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Nibbles 1,2 |A B C D|A B C D|
+-+-+-+-+-+-+-+-+
Nibbles 3,4 |A B C D|A B C D|
+-+-+-+-+-+-+-+-+
Nibble n |A B C D| (pad) |
(odd) & pad +-+-+-+-+-+-+-+-+
(a) The packet with (b) The packet without
the signaling structure the signaling structure
(bit S cleared) (bit S set)
Figure 4. The CESoPSN Packet Payload Format for Trunk-Specific Nx64
kbit/s
with CAS
Notes:
1. In case of T1-Nx64 kbit/s with CAS, the signaling bits are
carried in the TDM data as well as in the signaling
substructure. However, the receiver MUST use the CAS bits as
carried in the signaling substructures
2. It is possible to emulate trunk-specific Nx64 kbit/s services
with CAS by just carrying the trunk multiframe structures over
the PSN (and, in case of an E1 trunk, Nx64 kbit/s, including
timeslot 16 in the end service). Such an approach would be
fully consistent with the Principle of Minimum Intervention.
Its applicability is left for further study
3. In case of trunk-specific Nx64 kbit/s with CAS originating in
a T1-SF trunk, each nibble of the signaling substructure
contains A and B bits from two consecutive trunk multiframes
as described in [ATM-CES].
Vainshtein et al. Expires December 2003 [Page 17]
TDM Circuit Emulation Service over PSN June 2003
6.3. Unstructured Services
6.3.1. Basic Payload Format
For unstructured services, the payload of a CESoPSN packet consists of
a fixed number of octets filled with the raw TDM data received from the
incoming line. The packet payload size MUST be defined during the PW
setup, MUST be the same for both directions of the PW and MUST remain
unchanged for the life span of the PW.
All CESoPSN implementations MUST support the following packetization
latency (packet payload size) values:
1. E1: 1 millisecond (256 octets)
2. T1: 1 millisecond (193 octets)
3. E3: 125 microseconds (535 octets)
4. T3: 125 microseconds (699 octets).
Usage of any other packetization latency (packet payload size) is
OPTIONAL.
Note: The recommended packetization latency for E1 provides for
deployment of local methods for handling occasional loss of packets
that improve resilience of CEs to bursts of errors in the emulated
service that result from such a loss (see below).
6.3.2. Octet-aligned T1 Service
Support of Nx64 kbit/s services provides an additional option for
transferring unstructured T1:
o First, it is mapped into 25*DS0 bundle in accordance with the
rules described in [G.802]
o The 25*DS0 bundle is then carried over the PSN as an
appropriate CESoPSN PW.
Support of octet-aligned T1 service is OPTIONAL. CESoPSN
implementations supporting this service MUST support applicable set of
packetization latency values from Section 6.2.2.
7. CESoPSN Operation
7.1. Common Considerations
Edge-to-edge service emulation of a TDM service 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 Jitter buffer and de-packetizer at the PW egress.
Setup of a CESoPSN PW assumes exchange of the following information:
o Types of end services. In order to be connected by a CESoPSN
PW, these types MUST be the same and define the PW type.
Vainshtein et al. Expires December 2003 [Page 18]
TDM Circuit Emulation Service over PSN June 2003
Proposed values for the PW types supported by CESoPSN are
given in Annex C
o Bit rates of end services. In order to be connected, bit rates
of the two end services MUST be the same
o Encapsulation layer-specific parameters. These parameters are
described in Annex C
o Presence or absence of the 32-bit word with the zeroed first
nibble immediately after the bottom label in the label stack
(only for MPLS-enabled IP networks).
7.2. End Service Inactivity Behavior
For PWs carrying unstructured services, the PE MUST send "all ones"
code to its local PE while the PW is inactive.
For Nx64 kbit/s with and without CAS, while the PW is inactive the PE
MUST send some (locally configured) Idle Code to its local CE. For Nx64
kbit/s with CAS (logical or trunk-specific) it MUST also play out the
CAS bits values representing the Idle state of the telephony
application at the other end each of the DS0 channels (the specific
value is a local matter). In addition, it MAY also send a Force AIS
command to the Framer.
7.3. Description of the IWF operation
Once the PW is set up, the CESoPSN IWF operates like following:
7.3.1. PSN-bound Direction
o End service data is packetized in accordance with the number
of payload bytes specified.
o Sequence numbers and timestamps representing the selected
synchronization clock are inserted in the CESoPSN headers, and
appropriate flags (R, D, N, P and S) are set or cleared as
found fit
o CESoPSN, multiplexing and PSN headers are prepended to the
packetized service data
o Resulting packets are transmitted via the PSN.
Note: Indications of status of the TDM attachment circuit 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 Ability to emulate E1/T1 trunk behavior while carrying only
the actually used timeslots ("fractional E1/T1 applications,
see below).
The techniques to save the PSN switching capacity in case of an end
service outage are left for further study.
Vainshtein et al. Expires December 2003 [Page 19]
TDM Circuit Emulation Service over PSN June 2003
7.3.2. CE-bound Direction
The CE-bound IWF includes a jitter buffer that accumulates data from
incoming CESoPSN packets with their respective timestamps. The length
of this buffer SHOULD be configurable to allow adaptation to various
network delay behavior patterns. Size of the jitter buffer is a local
parameter of the CESoPSN IWF.
Initially the Jitter buffer is filled with the appropriate inactivity
code.
Immediately after start, the CESoPSN IWF instance:
o Enters the Loss of Packet Synchronization state. It will enter
the Normal state after a number of received consequent CESoPSN
packets has exceeded a locally configurable threshold (see
also below)
o 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.
o 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
o 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) 8 KHz transmission clock. 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
The CE-bound IWF SHOULD provide access to the value of the timestamp of
the packet that is currently played out. This value MAY be used for
synchronization between TDM data and CE application signals.
CESoPSN packets marked with an AIS or Idle Code indication in the
control word MUST be replaced with the appropriate amount of AIS (for
unstructured services) or Idle code (for structured services) in the
jitter buffer.
The CE-bound direction of the IWF:
o Performs detection, correlation and handling of CESoPSN faults
as described in Section 7.4 below
o Collects the PW Performance Monitoring data as defined in
Section 7.5 below
The CE-bound IWF for an Nx64 kbit/s service with or without CAS MAY be
configured to send the following commands to its NSP (see Annex B):
1. "Force AIS" command:
a) If it detects a Loss of Packet Synchronization condition
Vainshtein et al. Expires December 2003 [Page 20]
TDM Circuit Emulation Service over PSN June 2003
b) While it plays out CESoPSN packets with the AIS indication
set
2. "Force RAI" command - while it plays out CESoPSN packets with
the RAI indication set.
Notes:
1. The IWF configuration described above:
a) Is specific per IWF instance
b) Is a local issue. In particular, it is possible to
configure only one of the two IWF instances associated with
the given PW to force AIS and RAI states on its outgoing AC
c) Makes sense only if only one IWF instance associated with
the specific outgoing AC is configured in this way
2. If both IWF instances associated with the given PW are
configured to force AIS and RAI states on their respective
outgoing ACs, the CE devices may effectively treat the PW as
part of an emulated E1 or T1 service while the PSN carries
only an NX64 kbit/s service (thus possibly saving BW).
3. Extension of mechanisms allowing the CE-bound IWF to force
some special states on the outgoing AC to other services is
left for further study.
7.4. CESoPSN Defects
7.4.1. Misconnection
Some combinations of PSN and multiplexing layers inherently provide for
detection of packets that do not belong to the PW ('stray packets').
CESoPSN MAY use the SSRC field in the RTP header for detection of
'stray packets' even if such a capability is provided by the specific
combination of PSN and multiplexing layers.
Regardless of the way in which a stray packet has been detected:
o It MUST be discarded by the CE-bound IWF
o A counter of 'stray packets' must be incremented
If reception of stray packets persists above a configurable period of
time (by default, 2.5 seconds), the Misconnection alarm SHOULD be
reported to the management system. This alarm SHOULD be cleared if no
stray packets have been detected for a configurable period of time (by
default, 10 seconds).
The IWF mechanisms for detection of lost packets (e.g., expected next
sequence number) MUST NOT be affected by reception of 'stray packets'.
7.4.2. Re-Ordering and Loss of Packets
CESoPSN implementations SHOULD use sequence numbers in the RTP header
and expected rate of transmission of data packets for detection of our-
of-order delivery and packet loss. If RTP header is suppressed, they
MUST use the sequence number in the CESoPSN control word.
Vainshtein et al. Expires December 2003 [Page 21]
TDM Circuit Emulation Service over PSN June 2003
Out-of-order packets that cannot be reordered MUST be considered as
lost.
If loss of one or more CESoPSN packets has been detected at the egress
of the CESoPSN PW, its jitter buffer MUST be filled with the
appropriate amount of "replacement packets" in order to substitute
exactly one "replacement octet" for every lost octet of TDM data. The
content of these packets is a local matter. All CESoPSN implementations
MUST support generation of replacement packets filled with "all ones"
replacement octets for the TDM data. Use of other methods of generation
of "replacement packets" is OPTIONAL.
In addition:
1. A counter of lost packets must be incremented
2. If the number of consequent lost packets exceeds a locally
configurable threshold, the CESoPSN IWF instance enters the
Loss of Packet Synchronization state. While in this state:
a) All the CESoPSN data packets sent by the PSN-bound
direction of this IWF instance MUST be marked with the R
bit set in the CESoPSN control word
b) If the Loss of Packet Synchronization state persists above
a configurable period of time (by default, 2.5 seconds), a
Loss of Packets Synchronization alarm SHOULD be sent to the
management system.
3. Once the CESoPSN IWF is in the Loss of Packet Synchronization
state, it will (re-)enter its Normal state after it has
successfully received a number of CESoPSN packets that exceeds
another locally configurable threshold. Once the CESoPSN IWF
instance is in the Normal state:
a) All the CESoPSN data packets sent by the PSN-bound
direction of this IWF instance MUST be marked with the R
bit cleared in the CESoPSN control word
b) If the Normal state persists above a configurable period of
time (by default, 10 seconds), a previously reported Loss
of Packets Synchronization alarm SHOULD be cleared.
Note: Selected default packet payload size for unstructured E1 services
allows using the last received CESoPSN packet as a replacement packet
while preserving valid FAS. Such a mode of generation of replacement
packets prevents early detection of AIS or OOF condition by CEs using
simple E1 framers. The rest of the unstructured services are more
resilient to using "all ones" replacement packets (see [G.706] and
[G.775] for details). Structured services allow application-specific
generation of the replacement packets (e.g., per timeslot statistical
interpolation for Voice services, see [PACKETLOSS]). Trunk-specific
Nx64 kbit/s with CAS services require separate replacement techniques
for TDM data and signaling. It is RECOMMENDED to replace the latter
with the last received value(s) for all the timeslots.
7.4.3. Malformed Packets
CESoPSN PW detects a malformed packet using the following rules:
Vainshtein et al. Expires December 2003 [Page 22]
TDM Circuit Emulation Service over PSN June 2003
o The PT value in its RTP header does not correspond to one of
the PT values allocated for this direction of the 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.
If a malformed in-order packet has been received at the egress of a
CESoPSN PW, then:
o The packet MUST be discarded and appropriate amount of AIS (or
Idle Code) inserted in the jitter buffer
o A counter of malformed packets must be incremented
o If the payload mistype condition persists above a configurable
period of time (by default, 2.5 seconds), a Malformed Packets
alarm SHOULD be sent to the management system. This alarm
SHOULD be cleared if no malformed packets have been detected
for a configurable period of time (by default, 10 seconds).
7.4.4. Jitter Buffer Overrun
This fault is detected if the jitter buffer at the PW egress cannot
accommodate the newly arrived CESoPSN packet in its entirety.
A CESoPSN packet that cannot be stored in the jitter buffer MUST be
discarded.
If the jitter buffer overrun condition persists above a configurable
period of time (by default, 2.5 seconds), a Jitter Buffer Overrun alarm
should be sent to the management system. This alarm SHOULD be cleared
if no cases of overrun have been detected for a configurable period of
time (by default, 10 seconds).
Note: Jitter buffer underrun is in most cases undistinguishable from
the packet loss.
7.4.5. Remote Loss of Packet Synchronization
CESoPSN implementations SHOULD detect Remote Loss of Packet
Synchronization condition based upon the presence of the Remote Loss of
Packet Synchronization indication in the received packets. If the
Remote Loss of Packet Synchronization condition persists above a
configurable period of time (by default, 2.5 seconds), a Remote Loss of
Packet Synchronization alarm SHOULD be sent to the management system.
This alarm SHOULD be cleared if no packets with the Remote Loss of
Packet Synchronization indication have been received for a configurable
period of time (by default, 10 seconds).
Vainshtein et al. Expires December 2003 [Page 23]
TDM Circuit Emulation Service over PSN June 2003
7.5. Performance Monitoring
7.5.1. Errored Data Blocks
[G.826] defines the concept of an errored data block that serves as the
basis of for collection of performance monitoring parameters. It also
defines the size of the data block for most TDM circuits. These
definitions are aligned with the 'native circuit frame' size of these
circuits so that every G.826-compatible data block contains an integer
multiple of native circuit frames.
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
o An errored data block is a data block defined in accordance
with [G.826] that has experienced at least one error event
o A defect is insertion of a contiguous sequence of native
service frames of inactivity code into the jitter buffer if it
does not stem from receiving a CESoPSN packet with an AIS or
Idle Code indication and if the length of this sequence
exceeds the limits defined by the defect detection rules of
the emulated service.
7.5.2. Errored, Severely Errored and Unavailable Seconds
The definition of an errored data block presented above can be used to
define Errored Seconds, Severely Errored Seconds and Unavailable
Seconds in accordance with [G.826].
8. QoS Issues
If the PSN providing connectivity between PE devices is Diffserv-
enabled and provides a PDB [RFC3086] that guarantees low-jitter and
low-loss, the CESoPSN PW SHOULD use this PDB in compliance with the
admission and allocation rules the PSN has put in place for that PDB
(e.g., marking packets as directed by the PSN).
9. RTP Payload Format Considerations
In accordance with guidelines specified in [RFC2736], the following
issues are addressed by this specification:
9.1. Resilience to moderate loss of individual packets
The impact of loss of an individual data packet may be decreased by
decreasing the packet size (with the associated loss of efficiency).
For unstructured services, resilience of the CE at the egress of a
CESoPSN PW to loss of packets may be decreased by using intelligent
generation of "replacement packets". These techniques are most
appropriate for CESoPSN PWs carrying unstructured E1, and the default
Vainshtein et al. Expires December 2003 [Page 24]
TDM Circuit Emulation Service over PSN June 2003
packet payload size for these PWs has been selected as using
replacement of lost packet(s) with the last received one.
9.2. Ability to interpret every single packet
This requirement is always met for CESoPSN packets.
9.3. Non-usage of the RTP Header Extensions
This recommendation is met, since RTP-wise, the CESoPSN Control Word is
part of the RTP payload. Alignment with this requirement facilitates
usage of standard header compression mechanisms if CESoPSN uses UDP/IP
as its PSN and multiplexing layers.
9.4. Compression of RTP headers
Existing relevant standards ([RFC2508], [RFC3095]) deal with
compression of RTP/UDP/IP headers on specific P2P links. Compression
techniques defined in these documents are fully applicable for CESoPSN
if it uses UDP/IP as PSN and multiplexing layers respectively. Standard
compression of CESoPSN/UDP/IP headers will be very effective, since:
o Value of the SSRC field in the CESoPSN header of data packets
remains constant for the duration of a CESoPSN session
o Value of the Timestamp field in the CESoPSN header is usually
incremented by a fixed value from packet to packet
o CESoPSN control word is NOT defined as RTP header extension.
In addition to these methods, the RTP header shown in Fig. 1 MAY be
completely suppressed if the both PEs support such suppression. In this
case the sequence number in the CESoPSN control word MUST be used and
MUST be generated in accordance with rules stated in [RFC1889].
The resulting structure of the CESoPSN packet is shown in Fig. 5 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN and multiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|0 0 0 0 Reserved (OPTIONAL - only for an MPLS-enabled IP PSN) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word with mandatory sequence number |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Packetized TDM data (Payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. CESoPSN Packet Format with Suppressed RTP Header
If the RTP header has been compressed, the sequence number in the
CESoPSN control word MUST be used and MUST be generated according to
the same rules as if the RTP header were present. If the PSN is an
Vainshtein et al. Expires December 2003 [Page 25]
TDM Circuit Emulation Service over PSN June 2003
MPLS-enabled IP network employing proprietary ECMP techniques, the 32-
bit word with the zeroed first nibble SHOULD be inserted.
Note: The CESoPSN PWs carrying Nx64 kbit/s accompanied with CAS rely on
the RTP-based mixing techniques for synchronization between TDM data
and CE application signals. As a consequence, it is not permitted to
suppress the RTP header for these PWs.
10. Congestion Control (RFC 2914) Conformance
CESoPSN PWs represent a special case of PWs carrying constant bit rate
(CBR) services across the PSN. These services, by definition, cannot
behave in a TCP-friendly manner prescribed by [RFC2914] under
congestion while retaining any value for the user.
CESoPSN will use the generic PWE3 approach for handling congestion in
PWs carrying CBR services when such an approach has been specified.
11. FFS Issues
Note: This section will be removed from the final revision of the
document.
The following issues will be addressed in the next revisions of this
document:
o Applicability of trunk multiframe-aligned methods for carrying
trunk-specific Nx64 kbit/s with CAS
o Techniques for saving the PSN switching capacity when the PW
experiences an end service outage or does not carry any valid
data
o Effect of timestamp resolution on quality of clock recovery in
Differential mode
o Extension of techniques for forcing states on outgoing ACs to
emulation of other services
o Usage of extended control word for suppression of "idle"
channels in Nx64 kbit/s services with and without CAS.
12. Security Considerations
This document does not affect the underlying security issues of
specific PSN.
In addition, it defines misconnection detection capabilities of
CESoPSN. These capabilities increase resilience of CESoPSN to
misconfiguration and some types of DoS attacks.
Vainshtein et al. Expires December 2003 [Page 26]
TDM Circuit Emulation Service over PSN June 2003
13. Applicability Statement
CESoPSN is an encapsulation layer intended for carrying TDM circuits
(unstructured E1/T1/E3/T3, Nx64 kbit/s with or without CAS) over PSN.
CESoPSN allows, within reasonable limits, to emulate end-to-end delay
properties of TDM networks. In particular, in most cases the edge-to-
edge delay introduced by CESoPSN PWs does not depend upon the type and
bit-rate of the emulated service.
CESoPSN fully complies with the principle of minimal intervention
minimizing overhead and computational power required for encapsulation.
CESoPSN can be used in conjunction with various clock recovery
techniques and does not presume availability of a global synchronous
clock at the ends of a PW. However, if the global synchronous clock is
available at both ends of a CESoPSN PW, using RTP and differential mode
of timestamp generation improves the quality of the recovered clock.
CESoPSN allows carrying CE application state signaling that requires
synchronization with data 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 also allows emulation of Nx64 kbit/s services with CAS carrying
the signaling information appended to (some of) the packets carrying
TDM data.
CESoPSN complies with the recommendations for RTP payload specified in
[RFC2736]. The standard header compression techniques for RTP/UDP/IP
profile over slow and/or error-prone links are fully applicable to
CESoPSN PWs.
CESoPSN allows the PSN bandwidth conservation by carrying only AIS
and/or Idle Code indications instead of data.
CESoPSN allows deployment of BW-saving Fractional point-to-point E1/T1
applications. These applications can be described like following:
o The pair of CE devices operates as if they were connected by
an emulated E1 or T1 circuit. In particular they react to AIS
and RAI states of their local ACs in the standard way
o The PSN carries only an NX64 kbit/s service where N is the
number of actually used timeslots in the circuit connecting
the pair of CE devices thus saving the BW.
Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP-
friendly behavior under network congestion. If the service encounters
congestion, it should be temporarily shut down.
CESoPSN allows collection of TDM-like faults and performance monitoring
parameters hence emulating 'classic' carrier services of TDM circuits
Vainshtein et al. Expires December 2003 [Page 27]
TDM Circuit Emulation Service over PSN June 2003
(e.g., SONET/SDH). Similarity with these services is increased by the
CESoPSN ability to carry 'far end error' indications.
CESoPSN provides for a carrier-independent ability to detect
misconnections and malformed packets. This feature increases resilience
of the emulated service to misconfiguration and DoS attacks.
CESoPSN provides for detection of lost packets and allows using various
techniques for generation of "replacement packets". These techniques
increase resilience of CE to effects of lost packets and are of special
importance for emulation of unstructured E1 circuits.
CESoPSN carries indications of outages of incoming attachment circuit
across the PSN thus providing for effective fault isolation.
Faithfulness of a CESoPSN PW may be increased if the carrying PSN is
Diffserv-enabled and implements a PDB that guarantees low loss and low
jitter.
CESoPSN does not provide any mechanisms for protection against PSN
outages. As a consequence, resilience of the emulated service to such
outages is defined by the PSN behavior. On the other hand:
o The jitter buffer and packets' reordering mechanisms
associated with CESoPSN increase resilience of the emulated
service to fast PSN rerouting events
o Remote indication of lost packets is carried backward across
the PSN from the receiver (that has detected loss of packets)
to transmitter. Such an indication MAY be used as a trigger
for activation of proprietary service-specific protection
mechanisms.
CESoPSN does not provide for upgrade of existing devices using TDM
circuit emulation over ATM circuits to TDM circuit emulation over PSN.
14. IANA Considerations
This specification requires assignment of new PW Types for CESoPSN PWs
listed in Section 4.1.
15. Intellectual Property Disclaimer
This document is being submitted for use in IETF standards discussions.
Axerra Networks, Inc. has filed one or more patent applications
relating to the CESoPSN technology outlined in this document. Axerra
Networks, Inc. will grant free unlimited licenses for use of this
technology to the users who will register and sign up at the Axerra web
site.
ACKNOWLEDGEMENTS
We express deep gratitude to Stephen Casner who reviewed this document
in detail, corrected some serious errors and provided many valuable
inputs.
Vainshtein et al. Expires December 2003 [Page 28]
TDM Circuit Emulation Service over PSN June 2003
The present version of the text of the QoS section has been suggested
by Kathleen Nichols.
We thank Maximilian Riegel, Sim Narasimha, Tom Johnson, Ron Cohen and
Yaron Raz for valuable feedbacks.
We thank Yaakov (Jonathan) Stein for his constructive role in
preparation of a document that described emulation of unstructured TDM
services.
We thank Alik Shimelmits for many fruitful discussions.
MANDATORY REFERENCES
[RFC1122] R. Braden (ed.), Requirements for Internet Hosts --
Communication Layers, RFC 1122, IETF, 1989
[RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time
Applications, RFC 1889, IETF, 1996
[RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels,
RFC 2119, IETF, 1997
[RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC 2434, IETF, 1998
[RFC 2508] S.Casner, V. Jacobson, Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links, RFC 2508, IETF, 1999
[RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP Payload
Format Specifications, RFC 2736, IETF, 1999
[RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000
[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000
[RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated
Services Per Domain Behaviors and Rules for their Specification, RFC
3086, IETF, 2001
[RFC3095] C. Bormann (Ed.), RObust Header Compression (ROHC): Framework
and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF,
2001
[RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp-
parameters
[G.114] ITU-T Recommendation G.114 (05/2000) - International telephone
connections and circuits - Recommendations on the transmission quality
for an entire international telephone connection. One-way transmission
time
Vainshtein et al. Expires December 2003 [Page 29]
TDM Circuit Emulation Service over PSN June 2003
[G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit
Rates
[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s
hierarchical levels
[G.706] ITU-T Recommendation G.706 (04/91) - Frame Alignment and Cyclic
Redundancy Check (CRC) Procedures Relating to Basic Frame Structured
Defined in Recommendation G.704
[G.751] ITU-T Recommendation G.751 (xx/93) - Digital Multiplex
Equipments Operating at the Third Order Bit Rate of 34368 kbit/s and
the Fourth Order Bit Rate of 139264 kbit/s and Using Positive
Justification
[G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS),
Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect
Detection and Clearance Criteria for PDH Signals
[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.107] American National Standard for Telecommunications - Digital
Hierarchy - Format Specifications, ANSI T1.107-1988
[ATM-CES] The ATM Forum Technical Committee. Circuit Emulation Service
Interoperability Specification version 2.0 af-vtoa-0078.000, January
1997.
INFORMATIONAL REFERENCES
[PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation
Edge-to-Edge (PWE3), Work in Progress, December 2002, draft-ietf-pwe3-
requirements-04.txt
[PWE3-TDM-REQ] Maximilian Riegel et al, Requirements for Edge-to-Edge
Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in
Progress, February 2003, draft-ietf-pwe3-tdm-requirements-00.txt
[PWE3-ARCH] S. Bryant, P. Pate et al, Framework for Pseudo Wire
Emulation Edge-to-Edge (PWE3), Work in progress, June 2002, draft-ietf-
pwe3-framework-01.txt
[PWE3-SONET] A. Malis, P. Pate, SONET/SDH Circuit Emulation over Packet
(CEP), Work in progress, January 2003, draft-ietf-pwe3-sonet-01.txt
[PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire
Edge to Edge Emulation (PWE3), Work in progress, February 2003, draft-
ietf-pwe3-iana-allocation-00.txt
Vainshtein et al. Expires December 2003 [Page 30]
TDM Circuit Emulation Service over PSN June 2003
Authors' Addresses
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
email: sasha@axerra.com
Israel Sasson
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
email: israel@axerra.com
Akiva Sadovski
Axerra Networks
24 Raoul Wallenberg St.
Tel Aviv 69719, Israel
email: akiva@axerra.com
Eduard Metz
Thrupoint
Paasheuvelweg 16,
email: eduard.metz@hetnet.nl
Tim Frost
Zarlink Semiconductor
Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK
email: tim.frost@zarlink.com
Prayson Pate
Overture Networks
507 Airport Boulevard
Building 111 Morrisville, North Carolina, 27560
Email: prayson.pate@overturenetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Vainshtein et al. Expires December 2003 [Page 31]
TDM Circuit Emulation Service over PSN June 2003
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ANNEX A. A COMMON CE APPLICATION STATE SIGNALING MECHANISM
A PW that requires conveyance of CE application state signals that must
be synchronized with data carries encoded CE applications in special
signaling packets using:
o An additional PT value allocated for this purpose from the
range of unused values (see [IANA]). This value MUST be
different from one allocated for the TDM data packets for the
same PW
o An additional SSRC value that MUST be different from one used
for the data packets in order to allow a separate numbering
sequence for the signaling packets
o A sequence numbering scheme that does not depend on one used
for the data packets. This allows re-use of common sequence
numbers-based mechanisms (like reordering and detection of
lost packets) for the data packets for all types of circuits
Handling of loss of signaling packets is not required; as a
consequence, detection of loss of these packets is not required either.
The RTP header of the signaling packets is used in the following way:
1. V (version) is always set to 2
2. P (padding) MAY be used in accordance with the application-
specific CE state encoding rules
3. X (header extension) is always set to 0
4. CC (CSRC count) is always set to 0
5. M (marker) is set to 1 to for "urgent" signaling packets. The
CE application state carried in these packets will be
conveyed to the CE at the egress of the PW immediately,
without any re-synchronization with the data. State carried
in "normal" signaling packets will be conveyed to the CE at
the PW egress after re-synchronization with the TDM data
6. PT (payload type) is used to distinguish between packets
carrying the packetized TDM data and signaling packets. In
accordance with that, CESoPSN PWs using the CE application
state signaling mechanism MUST:
a) Allocate an additional PT value from the range of dynamic
values (see [RTP-TYPES]) for its signaling packets. The
Vainshtein et al. Expires December 2003 [Page 32]
TDM Circuit Emulation Service over PSN June 2003
allocation is done during the PW setup and MUST be the
same for both PW directions
b) The PE at the PW ingress MUST set the PT value in the RTP
header of signaling packets to the allocated value
c) The PE at the PW egress MUST use this value to
distinguish between TDM data and signaling packets.
7. The SSRC (synchronization source) value in the RTP header of
signaling packets MUST be different from that used by the
data packets
8. Sequence number is generated and processed in accordance with
the rules established in [RFC1889]. There should be no
connection between the sequence numbers used by the data and
signaling packets
9. Timestamps are used for re-synchronization between TDM data
and CE application state signals at the PW egress:
a) Their values are generated in accordance with the rules
established in [RFC1889]
b) Frequency of the clock used for generating timestamps
MUST be a multiple of 8 KHz and SHOULD be the same as
that used for the data packets
10. Each PE terminating the PW SHOULD send RTCP sender reports
(see RFC1889], Section 6.3.1) for the clock sources used for
generation of timestamps of both TDM data and signaling
packets to its peer:
a) These packets MAY be limited only to the header and
'Sender Info' sections
b) The PE receiving these packets SHOULD use the information
contained in the 'Sender Info' in order to map
(approximately) timestamps received in the signaling
packets to these received in the data packets.
Signaling packets are generated by the ingress PE in accordance with
the following logic (adapted from [RFC2833]):
1. The CESoPSN signaling packet with the same information is sent
3 times at an interval of 5 ms under one of the following
conditions:
a) The CESoPSN PW has been set up. These packets MUST be
marked as "urgent"
b) A change in the CE application state has been detected. If
another change of the CE application state has been
detected during the 15 ms period, this process continues
c) Loss of packets defect has been cleared. These packets
SHOULD be marked as "urgent"
d) Remote Loss of Packets indication has been cleared (after
previously being set) These packets SHOULD be marked as
"urgent"
2. Otherwise, the CESoPSN signaling packet with the current CAS
state information is sent every 5 seconds.
Vainshtein et al. Expires December 2003 [Page 33]
TDM Circuit Emulation Service over PSN June 2003
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.
Encoding of CE application state for various common applications will
be considered in separate documents.
ANNEX B. REFERENCE PE ARCHITECTURE FOR EMULATION OF NX64 KBIT/S
SERVICES
Structured TDM services do not exist as physical circuits. They are
always carried within appropriate physical attachment circuits (AC),
and the PE providing their emulation always includes a Native
Processing Block (NSP) commonly referred to as Framer. As a
consequence, the architecture of a PE device providing edge-to-edge
emulation for these services includes the Framer and Forwarder blocks.
In case of Nx64 kbit/s services (the only type of structured services
considered in this document), the AC is either an E1 or a T1 trunk, and
bundles of Nx64 kbit/s are cut out of it using one of the framing
methods described in [G.704].
In addition to detecting the FAS and imposing associated structure on
the "trunk" AC, E1 and T1 framers commonly support some additional
functionality including:
1. Detection of special states of the incoming AC (e.g., AIS, OOF
or RAI)
2. Forcing special states (e.g., AIS and RAI) on the outgoing AC
upon an explicit request
3. Extraction and insertion of CE application signals that may
accompany specific DS0 channel(s).
The resulting PE architecture for Nx64 kbit/s services is shown in Fig.
B.1 below. In this diagram:
1. In the PSN-bound direction:
a) The Framer:
i) Detects frame alignment signal (FAS) and splits the
incoming ACs into separate DS0 channels
ii) Detects special AC states
iii) If necessary, extracts CE application signals
accompanying each of the separate DS0 services
b) The Forwarder:
i) Creates one or more Nx64 kbit/s bundles
ii) Sends the data received in each such bundle to the
PSN-bound direction of a respective CESoPSN IWF instance
iii) If necessary, sends the current CE application state
data of the DS0 services in the bundle to the PSN-bound
direction of the respective CESoPSN IWF instance
iv) If necessary sends the AC state indications to the
PSN-bound directions of all the CESoPSN instances
associated with the given AC
Vainshtein et al. Expires December 2003 [Page 34]
TDM Circuit Emulation Service over PSN June 2003
c) Each PSN-bound PW IWF instance encapsulates the received
data, application state signal and the AC state into PW
PDUs and sends the resulting packets to the PSN
2. In the CE-bound direction:
i) Each CE-bound instance of the CESoPSN IWF receives the
PW PDUs from the PSN, extracts the TDM data, AC state
and CE application state signals and sends them
b) The Forwarder sends the TDM data, application state signals
and, if necessary, a single command representing the
desired AC state, to the Framer
c) The Framer accepts all the data of one or more NX64 kbit/s
bundles possibly accompanied by the associated CE
application state and commands referring to the desired AC
state, and generates a single AC accordingly with correct
FAS.
Notes: This model is asymmetric:
o AC state indication can be forwarded from the framer to
multiple instances of the CESoPSN IWF
o No more than one CESoPSN IWF instance should forward AC state-
affecting commands to the framer.
Vainshtein et al. Expires December 2003 [Page 35]
TDM Circuit Emulation Service over PSN June 2003
+------------------------------------------+
| PE Device |
+------------------------------------------+
| | Forwarder | |
| |---------------------| |
| | | |
| +<-- AC State---->- | |
| | | | |
| | | | |
E1 or T1 | | | | |
AC | | | | |
<=======>| |-----------------+---|--------------|
| | | | At most one |
| | |-->+ PW IWF |
| | | instance im- |
... | +<---NX64 kbit/s TDM Data-->+ posing state | PW Instance
| F | | on the X<===========>
| +<---CE App State --->+ outgoing AC |
E1 or T1 | R | | |
AC | +<--AC Command -------+ |
<=======>o A |---------------------|--------------|
| | ... | ... | ...
| M |-----------------+---|--------------|
| | | | Zero, one or |
| E | |-->+ more PW IWF |
| | | instances
| R +<---NX64 kbit/s TDM Data-->+ that do not | PW Instance
| | | impose state X<===========>
| +<---CE App State --->+ on the outgo-|
| | | ing AC |
+------------------------------------------+
Figure B.1. Reference PE Architecture for Nx64 kbit/s Services
ANNEX C. PAYLOAD AND ENCAPSULATION LAYER PARAMETERS
C.1 Payload Parameters
C.1.1. PW Types
PW types (a.k.a. VC types) have been defined in [PWE3-IANA]. PW types
used for CESoPSN PW are assigned in such a way as to avoid overlap with
types assigned in other PWE3 documents.
The following PW types are defined in this document for CESoPSN-based
PWs:
o Nx64 kbit/s - 65
o E1 - 66
o T1 - 67
o Octet-aligned T1 - 69
o E3 - 70
o T3 - 71
Vainshtein et al. Expires December 2003 [Page 36]
TDM Circuit Emulation Service over PSN June 2003
o E1 Nx64 kbit/s with CAS - 72
o T1 (ESF) Nx64 kbit/s with CAS - 73
o T1 (SF) Nx64 kbit/s with CAS - 74.
C.1.2. The Service Bit Rate
This parameter has been also defined in [PWE3-IANA], and is irrelevant
for PWs carrying unstructured services.
For Nx64 kbit/s services (with and without CAS) this parameter encodes
(as an integer) the number of DS0 channels that are carried by the PW.
C2. Encapsulation Layer Parameters
C2.1. Payload Bytes
This parameter has been defined in [PWE3-IANA]. In order to establish a
CESoPSN-based PW, the following conditions MUST be met:
1. The number of payload bytes MUST be the same for both
directions of the PW
2. The size of the resulting PW packet (including all the
headers) SHOULD NOT exceed the path MTU between the
participating PEs as provided by the Carrier layer.
Note: For PWs carrying logical Nx64 kbit/s with CAS this parameter
defines the number of payload bytes in the TDM data packets only.
C2.2 RTP-Related Parameters
The following parameters MUST be specified if RTP header is not
suppressed. Otherwise, they are irrelevant.
C2.2.1. RTP Payload Types
One PT value MUST be allocated from the range of dynamically allocated
payload types for each CESoPSN PW for use in the data packets as
described in Section 5.3.1 above.
For logical Nx64 kbit/s with CAS additional PT values MUST be allocated
from the range of dynamically allocated payload types for each
direction of the CESoPSN PW for use in the signaling packets so that:
o They MUST be different from the PT value(s) allocated for data
packets
o The same value MAY be re-used for both directions of the PW
o Ingress PW MUST set the PT in the RTP header of all the
signaling packets to the allocated value
o Egress PW MAY use this value to distinguish signaling PW
packets.
Note: The same PT value may be allocated for multiple PWs.
Vainshtein et al. Expires December 2003 [Page 37]
TDM Circuit Emulation Service over PSN June 2003
C2.2.2. Timestamp Resolution
This parameter encodes the rate of the clock used for setting
timestamps in RTP headers as a multiple of the basic 8 KHz rate.
C.2.2.3. Synchronization Source ID
The same 32-bit SSRC value MUST be assigned to all the data packets of
a given direction of a CESoPSN PW. The CE-bound direction of the IWF
MAY be use this value for misconnection detection, especially if such a
service is not provided by the PSN and/or multiplexing layer(s).
For PWs carrying logical Nx64 kbit/s with CAS, the signaling packets
MUST use a separate SSRC value.
C.2.2.4. Timestamp Generation Mode
This parameter encodes the selected timestamp generation mode. The
values assigned to the modes described in Section 5.2.1 are:
o Absolute (1) - the timestamps are generated in accordance
with the line clock of the incoming AC
o Differential (2) - the timestamps are generated in accordance
with a common reference clock of the pair of PEs.
Vainshtein et al. Expires December 2003 [Page 38]