Criteria for PDH Signals.
[G.802] ITU-T Recommendation G.802 (11/88) - Interworking
between Networks Based on Different Digital
Hierarchies and Speech Encoding Laws.
[G.826] ITU-T Recommendation G.826 (02/99) - Error performance
parameters and objectives for international, constant
bit rate digital paths at or above the primary rate.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules
for their Specification", RFC 3086, April 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D.
McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", RFC 4385,
February 2006.
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RTP-TYPES] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-
parameters>.
[T1.107] American National Standard for Telecommunications -
Digital Hierarchy - Format Specifications, ANSI
T1.107-1988.
15. Informative References
[ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) Circuit
Emulation Service Interoperability Specification Ver.
2.0.
[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T.,
and P. Pate, "TDM Circuit Emulation Service over
Packet Switched Network (CESoPSN)", Work in Progress,
November 2005.
[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F.
Balus, "Segmented Pseudo Wire", Work in Progress,
March 2006.
[PWE3-FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, November 2005.
[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual
Circuit Connectivity", Work in Progress, August 2005.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[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.
[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation
of Time Division Multiplexed (TDM) Circuits over
Packet Switching Networks", RFC 4197, October 2005.
[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol
Extensions for Setup of TDM Pseudowires", Work in
Progress, July 2005.
[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.
Appendix A: Old Mode of SAToP Encapsulation over L2TPv3
Previous versions of this specification defined a SAToP PW
encapsulation over L2TPv3, which differs from that described in
Section 4.3 and Figure 2b. In these versions, the RTP header, if
used, precedes the SAToP control word.
Existing implementations of the old encapsulation mode MUST be
distinguished from the encapsulations conforming to this
specification via the SAToP PW setup.
Appendix B: Parameters That MUST Be Agreed upon during the PW Setup
The following parameters of the SAToP IWF MUST be agreed upon between
the peer IWFs during the PW setup. Such an agreement can be reached
via manual configuration or via one of the PW setup protocols:
1. Type of the Attachment Circuit (AC)
As mentioned in Section 3, SAToP supports the following AC types:
i) E1 (2048 kbit/s)
ii) T1 (1544 kbit/s); this service is also known as DS1
iii) E3 (34368 kbit/s)
iv) T3 (44736 kbit/s); this service is also known as DS3
SAToP PWs cannot be established between ACs of different types.
2. Usage of octet-aligned mode for T1
a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs
is described in Section 5.2.
b) Both sides MUST agree on using this mode for a SAToP PW to be
operational.
3. Payload size, i.e., the amount of valid TDM data in a SAToP packet
a) As mentioned in Section 5.1:
i) The same payload size MUST be used in both directions of
the SAToP PW.
ii) The payload size cannot be changed once the PW has been set
up.
b) In most cases, any mutually agreed upon value can be used.
However, if octet-aligned T1 encapsulation mode is used, the
payload size MUST be an integral multiple of 25, and it
expresses the amount of valid TDM data including padding.
4. Usage of the RTP header in the encapsulation
a) Both sides MUST agree on using RTP header in the SAToP PW.
b) In the case of a SAToP PW over L2TPv3 using the RTP header,
both sides MUST agree on usage of the "old mode" described in
Appendix A.
5. RTP-dependent parameters. The following parameters MUST be agreed
upon if usage of the RTP header for the SAToP PW has been agreed
upon.
a) Timestamping mode (absolute or differential); this mode MAY be
different for the two directions of the PW, but the receiver
and transmitter MUST agree on the timestamping mode for each
direction of the PW
b) Timestamping clock frequency:
i) The timestamping frequency MUST be a integral multiple of 8
kHz.
ii) The timestamping frequency MAY be different for the two
directions of the PW, but the receiver and transmitter MUST
agree on the timestamping mode for each direction of the
PW.
c) RTP Payload Type (PT) value; any dynamically assigned value can
be used with SAToP PWs.
d) Synchronization Source (SSRC) value; the transmitter MUST agree
to send the SSRC value requested by the receiver.
Editors’ Addresses
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
EMail: sasha@axerra.com
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719, Israel
EMail: yaakov_s@rad.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).