Internet DRAFT - draft-frost-pwe3-timing-pw-reqs
draft-frost-pwe3-timing-pw-reqs
PWE3 Working Group T. Frost - Editor
INTERNET-DRAFT Silvana Rodrigues
Zarlink Semiconductor
Stewart Bryant
Cisco Systems Matthew Bocci
John Tatham
Yaakov Stein Alcatel
RAD Data Communications
Sasha Vainshtein
Ron Cohen Axerra Networks
Resolute Networks
Expires: September 2006 March 2006
Requirements for Pseudo Wires carrying Timing and Synchronization
draft-frost-pwe3-timing-pw-reqs-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes the requirements for the transmission of
network timing and synchronization across packet-switched networks
using pseudo-wires. Such services enable the function of real-time,
synchronous applications across the asynchronous packet switched
network. In particular, it complements the emulation of TDM bit
streams over the packet switched network.
Frost et al. Informational [Page 1]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
Table of Contents
1. Introduction......................................................2
2. Terminology and Reference Models..................................3
2.1. Terminology....................................................3
2.2. Reference Model................................................3
3. Aspects of Time and Frequency Synchronization over Packet Networks3
3.1. Current Approaches.............................................4
4. Applications......................................................5
4.1. Cellular Phone Network Infrastructure..........................5
4.2. Use in conjunction with TDM emulation..........................6
5. Requirements......................................................9
5.1. Performance Requirements.......................................9
5.2. Robustness requirements........................................9
5.2.1. Packet loss................................................9
5.2.2. Out-of-order delivery......................................9
5.2.3. Absolute delay............................................10
5.2.4. Delay Variation...........................................10
5.2.5. Congestion Control........................................10
5.2.6. Connection Defects........................................10
5.3. Redundancy requirements.......................................11
5.3.1. Redundancy and Failover...................................11
5.3.2. Synchronization quality indication........................11
6. Security Considerations..........................................11
7. References.......................................................12
1. Introduction
The PWE3 Working Group has produced several drafts related to the edge-
to-edge emulation of TDM circuits, e.g. [PWE3-SAToP], [PWE3-CESoPSN]
and [PWE3-TDMoIP]. These drafts all rely on the presence of accurate
timing at both edges of the network. Similarly, the use of ATM pseudo-
wires [PWE3-ATM] to carry AAL1 or AAL2 cells may also require accurate
timing at both edges. This timing may be recovered by some means from
the received packet stream, or distributed by some external means.
This document describes the requirements on distribution of accurate
network timing and synchronization over the packet network using
pseudo-wires, rather than using the conventional TDM synchronization
network.
It builds on the general requirements for pseudo-wire emulation
described in [RFC3916], and the architecture described in [RFC3985].
Frost et al. Expires September 2006 [Page 2]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
2. Terminology and Reference Models
2.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 [RFC3985], Section 1.4 are consistently used
without additional explanations.
2.2. Reference Model
The network reference model in Figure 2 of [RFC3985] applies to
customer applications requiring timing, where:
- CE1 is a master clock source of some type
- The attachment circuit is a physical means of distributing the
clock (for example, it could be a TDM circuit)
- CE2 is customer equipment requiring synchronization
There may be NSP units at both PE units to transform the clock, for
example the use of phase-locked loops (PLLs) to generate related
clock frequencies.
Some applications may require a bi-directional link, e.g. the
provision of a "time of day" reference. Other applications only
require the provision of a uni-directional link, e.g. those requiring
frequency and phase information.
3. Aspects of Time and Frequency Synchronization over Packet Networks
There are three aspects to the distribution of timing and
synchronization:
- Frequency distribution - i.e. the distribution of an accurate
frequency reference from one point to another
- Phase lock - i.e. the limiting of phase wander accumulation between
two clocks to a maximum value
- Time alignment - i.e. the synchronization of absolute time between
two or more points
Different applications require some or all of these three aspects. For
example, basestations for a cellular phone network all require to
operate at the same frequency (within a tolerance), to allow call
handoff from cell to cell. Traditional wired telecommunication
networks require both frequency and phase lock, to eliminate buffer
slips. Third generation CDMA cellular networks require each
Frost et al. Expires September 2006 [Page 3]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
basestation to have an absolute time reference, accurate to within a
given tolerance value.
3.1. Current Approaches
There are existing protocols for distribution of time synchronization
over packet networks. These include NTP (Network Time Protocol,
RFC1305), PTP (Precision Time Protocol, IEEE1588), and RTP (Real-time
Transfer Protocol, RFC3550).
NTP was developed for general synchronization of computer clocks over
the internet, to an accuracy of 1 to 50 ms. This is not sufficient
for many of the applications listed in section 4 below
IEEE1588 was developed for the industrial machine segment, where a
sub-microsecond accuracy was required. However, it was intended to be
used over dedicated networks, with specialized hardware to generate,
transmit and process the timing packets. It was not designed with a
general-purpose routed network in mind.
RTP was developed for transmission of real-time services (e.g. voice
and video) over a packet network. As such, the frequency of the
clock may be recovered from the arrival rate of packets and knowledge
of the clock used to generate the timestamp field, although many
applications of RTP do not require such clock recovery. The accuracy
is limited depending on the frequency of the timestamp clock.
3.2 Timing Pseudo-Wires
The use of pseudo-wires for timing transmission allows for customers
of a packet network operator to distribute their own timing in
parallel with their data networks. This timing will be contained
within their own pseudo-wires, and hence invisible to other
customers. Therefore multiple customers will be able to distribute
independent time services across their own pseudo-wire connections.
It is possible that existing protocols may be used within the pseudo-
wire (e.g. an NTP or IEEE1588 pseudo-wire), although existing
protocols may need modification before this is feasible. It should
be noted that both NTP and IEEE15888 are undergoing revision at this
time.
Frost et al. Expires September 2006 [Page 4]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
4. Applications
There are several applications that require timing and synchronization
services over packet networks:
- Cellular phone network infrastructure, for synchronization of
basestations to the basestation controller when migrating to a
packet-based backhaul infrastructure
- Use in conjunction with TDM emulation, to improve the quality of
timing available over TDM emulation services
- Real time services, e.g. synchronization of IP PBXs or VoIP gateways,
IP video services
- industrial machines, e.g. synchronization of computer controlled
robots over a factory network
- scientific applications, e.g. synchronization of radio telescopes for
long-baseline radio-astronomy
4.1. Cellular Phone Network Infrastructure
It is becoming common in cellular phone infrastructure to migrate
from leased-line TDM connections out to the basestation (e.g. E1 or
T1) to a packet-based connection. This reduces the cost of
For example, Figure 1 below shows a basestation controller connected
to two basestations via an ATM link. Traditionally this has
been carried over a TDM leased line, but in the diagram below this is
replaced by a pair of ATM pseudo-wires.
However, there is still a requirement for time services to the
basestation, which is provided naturally by the synchronous nature of
the TDM leased line. In this new configuration, a Time Server, driven
from the same Primary Reference Source (PRS) as the basestation
controller, is shown providing time and synchronization to the
basestations via a timing pseudo-wire.
The performance requirements for the cellular infrastructure
application varies depending on the type of cellular network. GSM and
UMTS FDD networks simply require accurate frequency distribution,
since there is a maximum frequency difference of 50ppb (parts per
billion) allowed between adjacent cells to permit efficient call
handoff. CDMA and UMTS TDD networks additionally require absolute
time synchronization of better than 10us.
Frost et al. Expires September 2006 [Page 5]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
\|/
|
+--------+ +-----+ +-----+ Clock +----+
| Time | Clock |.....|.......Timing PW1..| |-------| |
| Server |--------| | | PE1 | ATM | BS |
+--------+ |.....|..... ...ATM PW1...|.....|=======| |
| | | . . +-----+ +----+
| | | . .
PRS (~) | | . .
| | PE | .....
| | | . . \|/
+-------------+ | | . . |
| | | | . . +-----+ Clock +----+
| Basestation | ATM |.....|... ...Timing PW2..|.....|-------| |
| |=====| | | PE2 | ATM | BS |
| Controller | |.....|.........ATM PW2...|.....|=======| |
| | | | +-----+ +----|
+-------------+ +-----+
Figure 1: Use of Timing Pseudo-Wires in Cellular Infrastructure
4.2. Use in conjunction with TDM emulation
The following figures show how the use of a timing pseudo-wire can be
used in conjunction with the various synchronization scenarios for
TDM emulation described in [RFC4197], section 4.3. The clock
notation relates to the network synchronization reference model shown
in Figure 1 of [RFC4197].
o PE Synchronized Network
The common network reference clock "I" is available to both PE
devices, via transmission over pseudo-wire PW3.
PE Local oscillators "C" and "D" are locked to "I".
CE1 and CE2 use loop timing (i.e. time the output AC from the input).
Frost et al. Expires September 2006 [Page 6]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
|<------- Pseudo-wires ------->|
| |
| |<-- PSN Tunnel -->| |
V V V V
AC +-----+ +-----+ AC
+-----+ | | |==================| | | +-----+
| /-- |<---------|.............PW1..............|<---------| <-\ |
|| CE1| | | PE1 | | PE2 | | |CE2 ||
| \-> |--------->|.............PW2..............|--------->| --/ |
+-----+ | | | | | | +-----+
+->|.............PW3..............|--+
| | |==================| | |
| +-----+ +-----+ |
| ^ ^ |
| |C |D |
+-----+ +-----+
|
+-+
|I|
+-+
Figure 2: Relationship to the PE Synchronized Scenario
o CE Synchronized Network
The common network reference clock "L" is available to both CE
devices, via transmission over pseudo-wire PW3.
CE Local oscillators "A" and "G" are locked to "L".
PE1 and PE2 use loop timing (i.e. time the output AC from the input).
|<------- Pseudo-wires ------->|
| |
| |<-- PSN Tunnel -->| |
V V V V
AC +-----+ +-----+ AC
+-----+ | | |==================| | | +-----+
| |<---------|.............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|.............PW2..............|--------->| |
+-----+ | | | | | | +-----+
^ | | | | ^
|A | | | | G|
+------------>|.............PW3..............|--------------
| | |==================| |
+-+ +-----+ +-----+
|L|
+-+
Figure 3: Relationship to the CE Synchronized Scenario
Frost et al. Expires September 2006 [Page 7]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
o Relative Network Scenario
The common network reference clock "I" is available to both PE
devices, via transmission over pseudo-wire PW3.
Clocks "A" and "G" are generated locally without reference to a
common clock.
Timing information (the difference between the common reference
clock "I" and the incoming clock "A" or "G") is explicitly
transferred from the ingress PE to the egress PE.
Clocks "E" and "J" (the TDM output clocks at the egress PE - see
Fig. 1 of [RFC4197]) are generated in reference to the common
clock "I" using the timing information received from the ingress PE.
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).
|<------- Pseudo-wires ------->|
| |
| |<-- PSN Tunnel -->| |
V V V V |G
AC +-----+ +-----+ AC V
+-----+ | | |==================| | | +-----+
| |<---------|.............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|.............PW2..............|--------->| |
+-----+ | | | | | | +-----+
^ +->|.............PW3..............|--+
|A | | |==================| | |
| +-----+<-+ +->+-----+ |
| | | |
| | | |
+-----------+ +-----------+
|
+-+
|I|
+-+
Figure 4: Relationship to the Relative Network Scenario
o Adaptive Network Scenario
The adaptive network scenario does not require the presence of a
common clock at either CE or PE devices. Therefore it does not
require the use of a timing pseudo-wire.
Frost et al. Expires September 2006 [Page 8]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
5. Requirements
The requirements on Timing and Synchronization pseudo-wires may be
divided into the following groups:
- Performance requirements
- Connectivity and Compatibility Requirements
- Robustness requirements
- Redundancy requirements
- Security requirements
5.1. Performance Requirements
In general, performance requirements are dependent on the
application. Some applications will have much stricter requirements
on the quality of the clock than others. Therefore this document
will not attempt to define performance requirements, but leave this
to the relevant documents describing the various applications.
For example, Study Group 15, Question 13 of ITU is working on a
recommendation called [G.8261] that analyses synchronization
aspects for the transmission of TDM circuits over a packet network.
This document will set out the requirements for the synchronization
function of network elements where it is intended to connect such
services into the TDM network.
5.2. Robustness requirements
The robustness of the clock recovery mechanism depends upon the
proper handling of the following packet network effects:
- Packet loss
- Out-of-order delivery
- Absolute delay
- Packet delay variation (PDV)
- Congestion events
- Connection defects
5.2.1. Packet loss
The encapsulation layer MUST allow the egress PE to minimise the
effect of lost timing packets on the clock recovery process,
without requiring retransmission of the original packet.
5.2.2. Out-of-order delivery
The encapsulation layer MUST allow the egress PE to minimise the
effect of out-of-order delivery of timing packets on the clock
recovery process.
Frost et al. Expires September 2006 [Page 9]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
5.2.3. Absolute delay
The recovery of the clock MUST provide the ability to compensate
for absolute delay, whererequired by the application (e.g. for
those applications that require an absolute time reference).
Delay compensation MUST be achieved while maintaining jitter and
wander of the egress end service clock within tolerances specified
in the normative references for the application.
5.2.4. Delay Variation
Delay variation in packet networks is caused by a number of
different mechanims, including competition for resources within
network elements, output queuing, QoS mechanisms such as traffic
shaping, quantisation effects caused by the underlying physical
layer technology etc.
The recovery of the clock MUST provide for ability to compensate
for packet delay variation while maintaining jitter and wander of
the egress end service clock within tolerances specified in the
normative references for the application.
In particular, clocks to be used in the TDM network have
requirements on wander to be maintained within tolerance over very
long periods of time. As such, the clock recovery mechanism
SHOULD be immune to very low frequency packet delay variation,
such as that caused by different network usage levels throughout
the day.
5.2.5. Congestion Control
Unlike TDM circuits, the transfer of timing and synchronization
does not require a constant packet rate. Therefore, some means of
responding to congestion by reducing traffic load SHOULD be
provided, including in the limit, the ability to temporarily shut
down a Timing PW when severe congestion has been detected.
The egress PE MUST provide some means of maintaining the timing
and synchronization service to the CE under these conditions, e.g.
by providing "holdover" capability.
Further congestion considerations are discussed in chapter 6.5 of
[RFC3985].
5.2.6. Connection Defects
Misconnected packets are defined as packets that have been wrongly
identified as belonging to this pseudo-wire. If such packets pass
the classification stage, they may be identified by checking the
values of additional header fields, for example checking for an
invalid source address, cookie value or SSRC value.
Frost et al. Expires September 2006 [Page 10]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
Malformed packets are defined as packets that have passed the
classification stage and misconnection checks, but that are
malformed in some way, e.g. wrong length, or incorrect header or
payload format.
The encapsulation layer for timing PWs SHOULD, separately or in
conjunction with the lower layers of the PWE3 stack, provide the
ability to detect, report and discard both misconnected and
malformed packets.
5.3. Redundancy requirements
Timing and synchronization are heavily protected services in TDM
networks, and a redundancy strategy to allow failover to an
alternative timing source is always provided.
5.3.1. Redundancy and Failover
The ability for an egress PE to switch to an alternative timing
source MUST be provided. This alternative source MAY be another
packet timing connection, or an alternative physical clock source.
The switchover between the two MUST be transparent, so that the
timing and synchronization service is not affected.
Any resulting phase transient generated in the output clock MUST
be within the tolerances for a clock re-arrangement operation
specified in the normative references for the application.
5.3.2. Synchronization quality indication
The encapsulation layer SHOULD provide some means of indicating
the quality level of a clock to downstream equipment. This SHOULD
include indication of whether the master clock source has failed,
and as a result gone into a holdover condition. This indication
MAY be used by the egress PE to decide whether to switch over to
an alternative clock source, if available.
6. Security Considerations
The security considerations in [RFC3916] are fully applicable to the
transmission of network timing and synchronization. The ability to
disrupt synchronization services could be used as a key to disrupting
an entire network, and especially any real-time services carried over
the network. Therefore it is particularly important to know where a
source of packet timing is coming from, and whether it is genuine.
Therefore, it MUST be possible to provide some means of authentication
of timing PWs.
In addition these services are sensitive to packet delay variation, and
need to be protected from this as a method of attack.
Frost et al. Expires September 2006 [Page 11]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
7. References
[RFC1305] D. Mills, Network Time Protocol (Version 3) Specification,
Implementation", RFC1305, IETF, March 1992
[RFC2119] S. Bradner, "Key Words in RFCs to Indicate Requirement
Levels", RFC 2119, IETF, 1997
[RFC3916] XiPeng Xiao et al, "Requirements for Pseudo Wire Emulation
Edge-to- Edge (PWE3)", RFC3916, IETF, December 2004
[RFC3985] Stewart Bryant et al, "Pseudo Wire Emulation Edge-to-Edge
(PWE3) Architecture", RFC3985, IETF, March 2005
[RFC4197] M. Riegel (Ed.), "Requirements for Edge-to-Edge Emulation of
TDM Circuits over Packet Switched Networks", RFC4197, IETF, October
2005
[PWE3-SAToP] A. Vainshtein, Y. Stein, "Structure-Agnostic TDM over
Packet (SAToP)", Work in Progress, February 2006,
draft-ietf-pwe3-satop-05.txt
[PWE3-CESoPSN] A. Vainshtein et al, "Structure-Aware TDM Circuit
Emulation Services over Packet Switched Networks (CESoPSN)", Work in
Progress, November 2005, draft-ietf-pwe3-cesopsn-06.txt
[PWE3-TDMoIP] Y. Stein et al, "TDM over IP", Work in Progress,
September 2005, draft-ietf-pwe3-tdmoip-04.txt
[PWE3-ATM] L. Martini et al, "Encapsulation Methods for Transport of
ATM Over MPLS Networks", Work in Progress, September 2005,
draft-ietf-pwe3-atm-encap-10.txt
[IEEE1588] "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", IEEE Std.
1588-2002, November 2002
[G.8261] "Timing and Synchronization Aspects in Packet Networks",
ITU-T, Work in Progress, February 2006
Frost et al. Expires September 2006 [Page 12]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
Authors' Addresses
Tim Frost,
Zarlink Semiconductor,
Tamerton Road,
Roborough,
Plymouth,
PL6 7BQ, UK
Email: tim.frost@zarlink.com
Matthew Bocci, John Tatham
Alcatel
Grove House, Waltham Road Rd
White Waltham, Berks, UK. SL6 3TN
Email: matthew.bocci@alcatel.co.uk, john.p.tatham@alcatel.co.uk
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
Email: sasha@axerra.com
Stewart Bryant
Cisco Systems,
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom.
EMail: stbryant@cisco.com
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Email: mailto:yaakov_s@rad.com
Ron Cohen,
Resolute Networks Ltd.
Ligad Center
15 Central Avenue
P.O.Box 101, Modi'in Business Park
Modi'in 71700
Israel
Email: ronc@resolutenetworks.com
Silvana Rodrigues,
Zarlink Semiconductor,
400 March Road,
Kanata,
Ottawa,
Canada, K2K 3H4
Email: silvana.rodrigues@zarlink.com
Frost et al. Expires September 2006 [Page 13]
Internet Draft draft-frost-pwe3-timing-pw-reqs-01 March 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Frost et al. Expires September 2006 [Page 14]
