Figure 3: CE Synchronized Scenario
No timing information has to be transferred in these cases.
4.3.2. Relative Network Scenario
In this case, each CE uses its own transmission clock source that
must be carried across the PSN and recovered by the remote PE,
respectively. The common PE clock "I" can be used as reference for
this purpose.
Figure 4 shows the relative network scenario.
The common network reference clock "I" is available to all the PE
devices, and local oscillators "C" and "D" are locked to "I":
o Clocks "A" and "G" are generated locally without reference to a
common clock.
o Clocks "E" and "J" are generated in reference to a common clock
available at all PE devices.
In a slight modification of this scenario, one (but not both!) of the
CE devices may use its receive clock as its transmission clock (i.e.,
use loop timing).
|G
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+<-------+------->+-----+
|A |
+-+
|I|
+-+
Figure 4: Relative Network Scenario Timing
In this case, timing information (the difference between the common
reference clock "I" and the incoming clock "A") MUST be explicitly
transferred from the ingress PE to the egress PE.
4.3.3. Adaptive Network Scenario
The adaptive scenario is characterized by:
o No common network reference clock "I" is available to PE1 and PE2.
o No common reference clock "L" is available to CE1 and CE2.
Figure 5 presents the adaptive network scenario.
|J |G
v |
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+
| ^
A| E|
Figure 5: Adaptive Scenario
Synchronizing clocks "A" and "E" in this scenario is more difficult
than it is in the other scenarios.
Note that the tolerance between clocks "A" and "E" must be small
enough to ensure that the jitter buffer does not overflow or
underflow.
In this case, timing information MAY be explicitly transferred from
the ingress PE to the egress PE, e.g., by RTP.
5. Emulated Services
This section defines requirements for the payload and encapsulation
layers for edge-to-edge emulation of TDM services with bit-stream
payload as well as structured bit-stream payload.
Wherever possible, the requirements specified in this document SHOULD
be satisfied by appropriate arrangements of the encapsulation layer
only. The (rare) cases when the requirements apply to both the
encapsulation and payload layers (or even to the payload layer only)
will be explicitly noted.
The service-specific encapsulation layer for edge-to-edge emulation
comprises the following services over a PSN.
5.1. Structure-Agnostic Transport of Signals out of the PDH Hierarchy
Structure-agnostic transport is considered for the following signals:
o E1 as described in [G.704].
o T1 (DS1) as described in [G.704].
o E3 as defined in [G.751].
o T3 (DS3) as described in [T1.107].
5.2. Structure-Aware Transport of Signals out of the PDH Hierarchy
Structure-aware transport is considered for the following signals:
o E1/T1 with one of the structures imposed by framing as described
in [G.704].
o NxDS0 with or without CAS.
5.3. Structure-Aware Transport of SONET/SDH Circuits
Structure-aware transport is considered for the following SONET/SDH
circuits:
o SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3.
o SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c,
VC-4-16c, VC-4-64c.
o SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2.
o SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3.
Note: There is no requirement for the structure-agnostic transport of
SONET/SDH. For this case, it would seem that structure must be taken
into account.
6. Generic Requirements
6.1. Relevant Common PW Requirements
The encapsulation and payload layers MUST conform to the common PW
requirements defined in [RFC3916]:
1. Conveyance of Necessary Header Information:
A. For structure-agnostic transport, this functionality MAY be
provided by the payload layer.
B. For structure-aware transport, the necessary information MUST
be provided by the encapsulation layer.
C. Structure-aware transport of SONET/SDH circuits MUST preserve
path overhead information as part of the payload. Relevant
components of the transport overhead MAY be carried in the
encapsulation layer.
2. Support of Multiplexing and Demultiplexing if supported by the
native services. This is relevant for Nx DS0 circuits (with or
without signaling) and Nx VT-x in a single STS-1 SPE or VC-4.:
A. For these circuits, the combination of encapsulation and
payload layers MUST provide for separate treatment of every
sub-circuit.
B. Enough information SHOULD be provided by the pseudo wire to
allow multiplexing and demultiplexing by the NSP. Reduction
of the complexity of the PW emulation by using NSP circuitry
for multiplexing and demultiplexing MAY be the preferred
solution.
3. Intervention or transparent transfer of Maintenance Messages of
the Native Services, depending on the particular scenario.
4. Consideration of Per-PSN Packet Overhead (see also Section 7.5
below).
5. Detection and handling of PW faults. The list of faults is given
in Section 7.9 below.
Fragmentation indications MAY be used for structure-aware transport
when the structures in question either exceed desired packetization
delay or exceed Path MTU between the pair of PEs.
The following requirement listed in [RFC3916] is not applicable to
emulation of TDM services:
o Support of variable length PDUs.
6.2. Common Circuit Payload Requirements
Structure-agnostic transport treats TDM circuits as belonging to the
’Bit-stream’ payload type defined in [RFC3985].
Structure-aware transport treats these circuits as belonging to the
"Structured bit-stream" payload type defined in [RFC3985].
Accordingly, the encapsulation layer MUST provide the common
Sequencing service and SHOULD provide Timing information
(Synchronization services) when required (see Section 4.3 above).
Note: Length service MAY be provided by the encapsulation layer, but
is not required.
6.3. General Design Issues
The combination of payload and encapsulation layers SHOULD comply
with the general design principles of the Internet protocols as
presented in Section 3 of [RFC1958] and [RFC3985].
If necessary, the payload layer MAY use some forms of adaptation of
the native TDM payload in order to achieve specific, well-documented
design objectives. In these cases, standard adaptation techniques
SHOULD be used.
7. Service-Specific Requirements
7.1. Connectivity
1. The emulation MUST support the transport of signals between
Attachment Circuits (ACs) of the same type (see Section 5) and,
wherever appropriate, bit-rate.
2. The encapsulation layer SHOULD remain unaffected by specific
characteristics of connection between the ACs and PE devices at
the two ends of the PW.
7.2. Network Synchronization
1. The encapsulation layer MUST provide synchronization services
that are sufficient to:
A. match the ingress and egress end service clocks regardless of
the specific network synchronization scenario, and
B. keep the jitter and wander of the egress service clock within
the service-specific limits defined by the appropriate
normative references.
2. If the same high-quality synchronization source is available to
all the PE devices in the given domain, the encapsulation layer
SHOULD be able to make use of it (e.g., for better reconstruction
of the native service clock).
7.3. Robustness
The robustness of the emulated service depends not only upon the
edge-to-edge emulation protocol, but also upon proper implementation
of the following procedures.
7.3.1. Packet loss
Edge-to-edge emulation of TDM circuits MAY assume very low
probability of packet loss between ingress and egress PE. In
particular, no retransmission mechanisms are required.
In order to minimize the effect of lost packets on the egress
service, the encapsulation layer SHOULD:
1. Enable independent interpretation of TDM data in each packet by
the egress PE (see [RFC2736]). This requirement MAY be
disregarded if the egress PE needs to interpret structures that
exceed the path MTU between the ingress and egress PEs.
2. Allow reliable detection of lost packets (see next section). In
particular, it SHOULD allow estimation of the arrival time of the
next packet and detection of lost packets based on this estimate.
3. Minimize possible effect of lost packets on recovery of the
circuit clock by the egress PE.
4. Increase the resilience of the CE TDM interface to packet loss by
allowing the egress PE to substitute appropriate data.
7.3.2. Out-of-order delivery
The encapsulation layer MUST provide the necessary mechanisms to
guarantee ordered delivery of packets carrying the TDM data over the
PSN. Packets that have arrived out-of-order:
1. MUST be detected, and
2. SHOULD be reordered if not judged to be too late or too early for
playout.
Out-of-order packets that cannot be reordered MUST be treated as
lost.
7.4. CE Signaling
Unstructured TDM circuits would not usually require any special
mechanism for carrying CE signaling as this would be carried as part
of the emulated service.
Some CE applications using structured TDM circuits (e.g., telephony)
require specific signaling that conveys the changes of state of these
applications relative to the TDM data.
The encapsulation layer SHOULD support signaling of state of CE
applications for the relevant circuits providing for:
1. Ability to support different signaling schemes with minimal
impact on encapsulation of TDM data,
2. Multiplexing of application-specific CE signals and data of the
emulated service in the same PW,
3. Synchronization (within the application-specific tolerance
limits) between CE signals and data at the PW egress,
4. Probabilistic recovery against possible, occasional loss of
packets in the PSN, and
5. Deterministic recovery of the CE application state after PW setup
and network outages.
CE signaling that is used for maintenance purposes (loopback
commands, performance monitoring data retrieval, etc.) SHOULD use the
generic PWE3 maintenance protocol.
7.5. PSN Bandwidth Utilization
1. The encapsulation layer SHOULD allow for an effective trade-off
between the following requirements:
A. Effective PSN bandwidth utilization. Assuming that the size
of the encapsulation layer header does not depend on the size
of its payload, an increase in the packet payload size
results in increased efficiency.
B. 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 it decreases with the packet
payload size.
The compensation buffer used by the CE-bound IWF increases
latency to the emulated circuit. Additional delays introduced by
this buffer SHOULD NOT exceed the packet delay variation observed
in the PSN.
2. The encapsulation layer MAY provide for saving PSN bandwidth by
not sending corrupted TDM data across the PSN.
3. The encapsulation layer MAY provide the ability to save the PSN
bandwidth for the structure-aware case by not sending channels
that are permanently inactive.
4. The encapsulation layer MAY enable the dynamic suppression of
temporarily unused channels from transmission for the structure-
aware case.
If used, dynamic suppression of temporarily unused channels
MUST NOT violate the integrity of the structures delivered over
the PW.
5. For NxDS0, the encapsulation layer MUST provide the ability to
keep the edge-to-edge delay independent of the service rate.
7.6. Packet Delay Variation
The encapsulation layer SHOULD provide for the ability to compensate
for packet delay variation, while maintaining jitter and wander of
the egress end service clock with tolerances specified in the
normative references.
The encapsulation layer MAY provide for run-time adaptation of delay
introduced by the jitter buffer if the packet delay variation varies
with time. Such an adaptation MAY introduce a low level of errors
(within the limits tolerated by the application) but SHOULD NOT
introduce additional wander of the egress end service clock.
7.7. Compatibility with the Existing PSN Infrastructure
The combination of encapsulation and PSN tunnel layers used for edge-
to-edge emulation of TDM circuits SHOULD be compatible with existing
PSN infrastructures. In particular, compatibility with the
mechanisms of header compression over links where capacity is at a
premium SHOULD be provided.
7.8. Congestion Control
TDM circuits run at a constant rate, and hence offer constant traffic
loads to the PSN. The rate varying mechanism that TCP uses to match
the demand to the network congestion state is, therefore, not
applicable.
The ability to shut down a TDM PW when congestion has been detected
MUST be provided.
Precautions should be taken to avoid situations wherein multiple TDM
PWs are simultaneously shut down or re-established, because this
leads to PSN instability.
Further congestion considerations are discussed in chapter 6.5 of
[RFC3985].
7.9. Fault Detection and Handling
The encapsulation layer for edge-to-edge emulation of TDM services
SHOULD, separately or in conjunction with the lower layers of the
PWE3 stack, provide for detection, handling, and reporting of the
following defects:
1. Misconnection, or Stray Packets. The importance of this
requirement stems from customer expectation due to reliable
misconnection detection in SONET/SDH networks.
2. Packet Loss. Packet loss detection is required to maintain clock
integrity, as discussed in Section 7.3.1 above. In addition,
packet loss detection mechanisms SHOULD provide for localization
of the outage in the end-to-end emulated service.
3. Malformed packets.
7.10. Performance Monitoring
The encapsulation layer for edge-to-edge emulation of TDM services
SHOULD provide for collection of performance monitoring (PM) data
that is compatible with the parameters defined for ’classic’,
TDM-based carriers of these services. The applicability of [G.826]
is left for further study.
8. Security Considerations
The security considerations in [RFC3916] are fully applicable to the
emulation of TDM services. In addition, TDM services are sensitive
to packet delay variation [Section 7.6], and need to be protected
from this method of attack.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[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 structures defined in Recommendation G.704
[G.707] ITU-T Recommendation G.707 (10/00) - Network node
interface for the synchronous digital hierarchy (SDH)
[G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of 34
368 Kbit/s and the fourth order bit rate of 139 264
Kbit/s and using positive justification
[G.810] ITU-T Recommendation G.810 (08/96) - Definitions and
terminology for synchronization networks
[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
[Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to
CCITT Signalling System No. 7
[Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
interface layer 3 specification for basic call control
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of
RTP Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -
Basic Description including Multiplex Structure, Rates,
and Formats, May 2001
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
[TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and
Objectives, Bellcore, TR-NWT-170, January 1993
10. Contributors Section
The following have contributed to this document:
Sasha Vainshtein
Axerra Networks
EMail: sasha@axerra.com
Yaakov Stein
RAD Data Communication
EMail: yaakov_s@rad.com
Prayson Pate
Overture Networks, Inc.
EMail: prayson.pate@overturenetworks.com
Ron Cohen
Lycium Networks
EMail: ronc@lyciumnetworks.com
Tim Frost
Zarlink Semiconductor
EMail: tim.frost@zarlink.com
Author’s Address
Maximilian Riegel
Siemens AG
St-Martin-Str 76
Munich 81541
Germany
Phone: +49-89-636-75194
EMail: maximilian.riegel@siemens.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.