Transparent SDH/SONET over Packet
draft-manhoudt-pwe3-tsop-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Gert Manhoudt , Stephan Roullot , Peter Roberts | ||
| Last updated | 2012-07-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-manhoudt-pwe3-tsop-00
INTERNET-DRAFT G. Manhoudt
Intended Status: Proposed Standard AimValley
Expires: December 16, 2012
S. Roullot
Alcatel-Lucent
P. Roberts
Alcatel-Lucent
July 09, 2012
Transparent SDH/SONET over Packet
draft-manhoudt-pwe3-tsop-00
Abstract
This document describes the Transparent SDH/SONET over Packet (TSoP)
mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or
Synchronous Optical NETwork (SONET) bit-streams in a packet format,
suitable for Pseudowire (PW) transport over a packet switched network
(PSN). The key property of the TSoP method is that it transports
the SDH/SONET client signal in its entirety through the PW, i.e., no
use is made of any specific characteristic of the SONET/SDH signal
format, other than its bit rate. The TSoP transparency includes
transporting the timing properties of the SDH/SONET client signal.
This ensures a maximum of transparency and a minimum of complexity,
both in implementation and during operation.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
Manhoudt et al. Expires December 16, 2012 [Page 1]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Manhoudt et al. Expires December 16, 2012 [Page 2]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Acronyms and Terms . . . . . . . . . . . . . . . . . . . . 5
3. Emulated STM-N Services . . . . . . . . . . . . . . . . . . . 6
3.1 PSN-bound direction . . . . . . . . . . . . . . . . . . . . 8
3.1 CE-bound direction . . . . . . . . . . . . . . . . . . . . 9
4. TSoP Encapsulation Layer . . . . . . . . . . . . . . . . . . . 11
4.1. TSoP Packet Format . . . . . . . . . . . . . . . . . . . . 11
4.2. PSN/PW Headers . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Transport over an MPLS(-TP) PSN . . . . . . . . . . . . 11
4.2.2 Transport over an IPv4/IPv6 PSN . . . . . . . . . . . . 12
4.3. TSoP Encapsulation Headers . . . . . . . . . . . . . . . . 12
4.3.1. Location and Order of TSoP Encapsulation Headers . . . 12
4.3.2. Usage and Structure of the TSoP Control Word . . . . . 14
4.3.3. Usage of the RTP Header . . . . . . . . . . . . . . . 15
5. TSoP Payload Field . . . . . . . . . . . . . . . . . . . . . . 17
6. TSoP Operation . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Common Considerations . . . . . . . . . . . . . . . . . . 17
6.2. IWF Operation . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. PSN-Bound Direction . . . . . . . . . . . . . . . . . 17
6.2.2. CE-Bound Direction . . . . . . . . . . . . . . . . . . 18
6.3. TSoP Defects . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. TSoP Performance Monitoring . . . . . . . . . . . . . . . 21
7. Quality of Service (QoS) Issues . . . . . . . . . . . . . . . 23
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Applicability Statements . . . . . . . . . . . . . . . . . . . 25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Parameters to be configured to set up a TSoP PW . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Manhoudt et al. Expires December 16, 2012 [Page 3]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
1. Introduction
This document describes the Transparent SDH/SONET over Packet (TSoP)
method for encapsulating SDH or SONET signals with bit rates of
51.84 Mbit/s or N * 155.52 Mbit/s (where N = 1, 4, 16 or 64) for
Pseudowire (PW) transport over a packet switched network (PSN), using
circuit emulation techniques.
The selected approach for this encapsulation scheme avoids using any
particular signal characteristics of the SDH/SONET signal, other than
its bit rate. This approach closely follows the SAToP method
described in [RFC4553] for PW transport of E1, DS1, E3 or DS3 over a
PSN.
An alternative to the TSoP method for STM-N transport over PW is
known as CEP (Circuit Emulation over Packet) and is described in
[RFC4842]. The key difference between the CEP approach and the TSoP
approach is that within CEP an incoming STM-N is terminated and
demultiplexed to its constituent VCs (Virtual Containers).
Subsequently, each VC is individually circuit emulated and
encapsulated into a PW and transported over the PSN to potentially
different destinations, where they are reassembled into (newly
constructed) STM-N signals again. The TSoP approach, on the other
hand, is to encapsulate the entire STM-N in a single circuit
emulating Pseudowire and transport it to a single destination over
the PSN. The essential difference between both methods is that CEP
offers more routing flexibility and better bandwidth efficiency than
TSoP at the cost of the loss of transparency (overhead, timing,
scrambling) at the STM-N layer and at the cost of added complexity
associated with the inclusion of what in essence is an SDH/SONET VC
cross-connect function in the PEs.
Within the context of this document, there is no difference between
SONET [GR-253] signals, often denoted as OC-M, and SDH [G.707]
signals, usually denoted as STM-N. For ease of reading, this document
will only refer to STM-N, but any statement about an STM-N signal
should be understood to apply equally to the equivalent OC-M signal,
unless it is specifically mentioned otherwise. The equivalency can
be described by the following relations between N and M: If N = 0
then M = 1 and if N >= 1 then M = 3 * N.
The TSoP solution presented in this document conforms to the PWE3
architecture described in [RFC3985] and satisfies the relevant
general requirements put forward in [RFC3916].
As with all PWs, TSoP PWs may be manually configured or set up using
the PWE3 control protocol [RFC4447].
Manhoudt et al. Expires December 16, 2012 [Page 4]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
2. Terminology and Conventions
2.1. Conventions Used in This Document
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 RFC 2119 [RFC2119].
2.2. Acronyms and Terms
The following acronyms used in this document are defined in
[RFC3985], [RFC4197] and [RFC4553]:
AC Attachment Circuit
ATM Asynchronous Transfer Mode
CE Customer Edge
CES Circuit Emulation Service
IWF Interworking Function
NSP Native Service Processing
PE Provider Edge
PREP Pre-Processing
PSN Packet Switched Network
PW Pseudowire
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
TDM Time Division Multiplexing
In addition, the following specific terms are used in this document:
LOF Loss Of Frame - A condition of an STM-N signal in which the
frame pattern cannot be detected. Criteria for raising and
clearing a LOF condition can be found in [G.783].
LOS Loss Of Signal - A condition of the STM-N attachment circuit
in which the incoming signal has an insufficient energy
level for reliable reception. Criteria for raising and
clearing a LOS condition can be found in [G.783].
G-AIS Generic Alarm Indication Signal - A specific bit pattern
that replaces the normal STM-N signal in the case of certain
failure scenarios. The G-AIS pattern [G.709] is constructed
by continuously repeating the 2047 bit pseudo random bit
sequence based on the generating polynomial 1 + x^9 + x^11
according to [O.150].
NIM Non-Intrusive Monitor - A circuit that monitors a signal in
a certain direction of transmission, without changing the
binary content of it. A NIM can be used for Fault Management
Manhoudt et al. Expires December 16, 2012 [Page 5]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
and Performance Monitoring purposes
SF Signal Fail: A control signal, that exists internally in a
system, to convey the failed state of an incoming signal,
from a server layer process to the adjacent client layer
process. See [G.783]
LOPS Loss of Packet State - A defect that indicates that the PE
at the receiving end of a TSoP carrying PW experiences an
interruption in the stream of received TSoP packets. See
[RFC5604]
3. Emulated STM-N Services
The TSoP emulated STM-N service over a Pseudowire makes use of a bi-
directional point-to-point connection over the PSN between two TSoP-
IWF blocks, located in the PE nodes that terminate the PW that
interconnects them, as shown in figure 1. The TSoP-IWF blocks each
consist of two half-functions, a PSN-bound IWF and a CE-bound IWF,
one for each direction of transmission. As the name implies, the PSN-
bound part of the TSoP IWF performs the conversion of an STM-N
bitstream to a packet flow, suitable for transport over the PSN and
the CE-bound part of the TSoP-IWF performs the inverse operation.
Manhoudt et al. Expires December 16, 2012 [Page 6]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
|<------------------ Emulated Service ----------------->|
| |
| |<-------------- Pseudowire ------------->| |
| AC | | AC |
|<---->| |<----- PSN ----->| |<---->|
| | | | | |
| . PE1 . . PE2 . |
. +-----------+ +-----------+ .
+---+ | | | | +---+
| |----->| PSN-bound |====> . . . ====>| CE-bound |----->| |
| C | | IWF | | IWF | | C |
| E | | _ _ _ | | _ _ _ | | E |
| | | | | | | |
| 1 | | | | | | 2 |
| |<-----| CE-bound |<==== . . . <====| PSN-bound |<-----| |
+---+ | | IWF | | IWF | | +---+
| +-----------+ +-----------+ |
| TSoP-IWF TSoP-IWF |
native native
STM-N STM-N
Figure 1. Overview of STM-N emulated service architecture
The following list provides the STM-N services, as specified in
[G.707] and [GR-253], that can be supported by a TSoP PW:
1. STM-0 or OC-1 (51.84 Mbit/s)
2. STM-1 or OC-3 (155.52 Mbit/s)
3. STM-4 or OC-12 (622.08 Mbit/s)
4. STM-16 or OC-48 (2488.32 Mbit/s)
5. STM-64 or OC-192 (9953.28 Mbit/s)
The TSoP protocol used for emulation of STM-N services does not
depend on the method in which the STM-N is delivered to the PE. For
example, an STM-1 attachment circuit is treated in the same way
regardless of whether it is a copper [G.703] or a fiber optic [G.707]
link.
Also, in case the STM-N is carried in an OTN signal [G.709], the
functionality in the TSoP-IWF operates in the same way, but a PWE3
Pre-processing (PREP) functional block will be present between the AC
and the PE to perform the OTN (de)multiplexing functions.
The TSoP-IWF function in figure 1 is further broken down in
functional blocks in figure 2. These individual functional blocks
are described in the next two sections.
Manhoudt et al. Expires December 16, 2012 [Page 7]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
AC TSoP-IWF PSN
------>|<------------------------------------------------->|<--------
+---------------------------------------------------+
| +-------+ |
| +-------+ SF | PSN- | CE-side_ |
| | |----->| bound | defect +--------+ |
STM-N | | STM-N | +->| NIM |------------>| | |
=========>| Rx | | +-------+ | | |
| | |===0=======================>| PSN- | | Packet
| +-------+ +--------+ | bound |===========>
| | Subst. | | IWF | |
| | Signal |===========>| | |
| | Gen. | +-->| | |
| +--------+ | +--------+ |
| | |
| PSN-bound direction | |
- - - -|- - - - - - - - - - - - - - - - - -|- - - - - - - -|- - - - -
| CE-bound direction | |
| | |
| +--------+ | PSN-side_ |
| | G-AIS | | defect |
| | Gen. |====+ | |
| +--------+ | | |
| | | +--------+ |
| +--------+ | +---| | |
| +-------+ | |<===+ | | |
| | | | STM-N/ | No_Packet | CE- | |
<=========| STM-N |<=====| G-AIS |<-----------| bound |<===========
STM-N | | Tx | | Switch | | IWF | | Packet
| | | +-->| |<========0==| | |
| +-------+ | +--------+ | | | |
| | +----------+ | +--------+ |
| | | optional | | |
| +------| CE-bound |<---+ |
| | NIM | |
| +----------+ |
+---------------------------------------------------+
Figure 2. TSoP functional block diagram
3.1 PSN-bound direction
In the PSN-bound direction the STM-N signal is received from the CE
via an AC by the STM-N Rx function. This function recovers the
optical or electrical signal and converts it to a suitable internal
format. In addition, it detects the LOS condition and it asserts the
SF signal whenever this is the case. The STM-N Rx block is
Manhoudt et al. Expires December 16, 2012 [Page 8]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
equivalent to the OSn_TT_Sk & OSn/RSn_A_Sk (in the case of an optical
STM-N) or the ESn_TT_Sk & ESn/RSn_A_Sk (in the case of an electrical
STM-N interface) function pairs defined in [G.783].
The CE-bound IWF segments the STM-N ingress bitstream, which it
receives from the STM-N Rx function, in blocks of equal length. Each
block of bits is supplied with the appropriate TSoP Encapsulation
Headers and then delivered to the PSN Multiplexing layer to add the
required headers for transport over the PSN.
The PSN-bound NIM function controls the state of the CE-side_defect
signal. It will assert this signal in case the SF signal is asserted
or in case another defect is detected in the incoming STM-N signal.
The inclusion of other defects than LOS in the CE-side_defect signal
is OPTIONAL.
When the CE-side_defect signal is asserted, the PSN-bound IWF will
set the corresponding flag (L-bit) in the overhead of the affected
packets. Packets in which the L-bit is set MUST have a substitution
payload (created by the Substitution Signal Generator function) of
the same length as the regular TSoP payload. This substitution
payload is RECOMMENDED to be the G-AIS pattern or a fixed "all ones"
pattern.
Lastly, when the PSN-side_defect state is asserted, the PSN-bound IWF
will set the corresponding flag (R-bit) in the overhead of all
packets that are transmitted while this signal is in the asserted
state.
3.1 CE-bound direction
In the CE-bound direction, the CE-bound IWF receives the PW packets
from the PSN and strips off the PSN, PW, and TSoP encapsulation
headers and writes the payload data in a buffer. The output data
stream towards the CE is created by playing out this buffer with a
suitable clock signal. The thus reconstructed STM-N signal is
forwarded to the STM-N/G-AIS Switch function.
The No_Packet signal is asserted by the CE-bound IWF in case the
internal packet buffer empties due to lack of input packets from the
PSN or in case a packet is missing or invalid.
The PSN-side_defect signal is asserted by the CE-bound IWF in case
the LOPS condition is detected by the CE-bound IWF (see section
6.2.2). The state of this signal controls the value of the R-bit in
the overhead of the packets returned towards the far-end TSoP-IWF.
The G-AIS Generator generates a G-AIS signal at the nominal frequency
Manhoudt et al. Expires December 16, 2012 [Page 9]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
of the recovered STM-N signal, +/-20 ppm.
The STM-N/G-AIS Switch normally takes its input from the CE-bound IWF
and forwards the recovered STM-N signal towards the STM-N Tx
funnction, but during the time that the No_Packet signal is asserted,
it will select the G-AIS Generator as its active input and forward a
G-AIS signal towards the STM-N Tx function.
The CE-bound NIM function is an OPTIONAL function that can be used to
detect additional defects in the recovered CE-bound STM-N signal.
The presence of such defects (e.g. STM-N LOF) MAY be used as an
additional reason for the STM-N/G-AIS Switch function to select the
G-AIS signal as its active input.
Lastly, the STM-N Tx function converts the internal signal that is
output by the STM-N/G-AIS Switch block into a regular STM-N signal
towards the CE via the AC. The STM-N Tx block is equivalent to the
OSn_TT_So & OSn/RSn_A_So (in the case of an optical STM-N) or the
ESn_TT_So & ESn/RSn_A_So (in the case of an electrical STM-N
interface) function pairs defined in [G.783].
Manhoudt et al. Expires December 16, 2012 [Page 10]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
4. TSoP Encapsulation Layer
4.1. TSoP Packet Format
The general format of TSoP packets during transport over the PSN is
shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN/PW Headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TSoP Encapsulation Headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| ... |
| |
| TSoP Payload Field |
| |
| ... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Generic TSoP Packet Format
4.2. PSN/PW Headers
A TSoP PW can be transported over different types of PSNs based on
different switching technology. Below the transmission over MPLS and
IPv4/IPv6 PSNs is described, but other methods are not precluded.
The selected method will determine the format of the PSN/PW Headers
part and influence the order of the fields in the TSoP Encapsulation
Headers part.
4.2.1 Transport over an MPLS(-TP) PSN
In case a TSoP PW is forwarded over an MPLS(-TP) PSN, a standard
"bottom of stack" PW label as shown in figure 4 is prepended before
the TSoP Encapsulation Headers. Subsequently, one or more MPLS(-TP)
labels need to be pushed according to the standard MPLS transport
methods outlined in [RFC3031] and [RFC3032].
Manhoudt et al. Expires December 16, 2012 [Page 11]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. PW Label (S = 1)
4.2.2 Transport over an IPv4/IPv6 PSN
Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing
mechanisms for TSoP PWs over an IPv4/IPv6 PSN. The PW label
(figure 4) provides the demultiplexing function for an IPv4/IPv6 PSN
as described in [RFC3985]. The total length of a TSoP packet for a
specific PW MUST NOT exceed path MTU between the pair of PEs
terminating this PW. TSoP implementations using an IPv4 PSN MUST
mark the IPv4 datagrams they generate as "Don't Fragment" [RFC791]
(see also [RFC4623]).
4.3. TSoP Encapsulation Headers
4.3.1. Location and Order of TSoP Encapsulation Headers
The TSoP Encapsulation Headers MUST contain the TSoP Control Word
(figure 7) and MUST contain a Minimum length RTP Header [RFC3550]
(figure 8). The TSoP Encapsulation Headers must immediately follow
the PSN/PW header, as shown in figure 3.
In case the TSoP packets are transmitted over a PSN based on UDP over
IPv4/IPv6 technology, the TSoP Encapsulation Headers have the RTP
Header first and then the TSoP control word immediately next, as
shown in figure 6. In case the TSoP packets are transmitted over a
PSN based on a technology other than UDP over IPv4/IPv6, the TSoP
Encapsulation Headers have the TSoP control word first and then the
RTP header immediately next, as shown in figure 5.
Note: This arrangement complies with the traditional usage of RTP for
the IPv4/IPv6 PSN with UDP multiplexing while making TSoP PWs Equal
Cost Multi-Path (ECMP)-safe for the MPLS PSN by providing for PW-IP
packet discrimination (see [RFC3985]). Furthermore, it facilitates
seamless stitching of L2TPv3-based and MPLS-based segments of TSoP
PWs (see [RFC5254]).
Manhoudt et al. Expires December 16, 2012 [Page 12]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
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/PW Headers |
| (Ethernet, MPLS(-TP), IPv4/IPv6 + L2TPv3, etc.) |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TSoP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- --+
| Minimum length RTP Header (see [RFC3550]) |
+-- --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. General TSoP Packet Format for all PSNs, other
than an IPv4/IPv6 PSN with UDP PW Demultiplexing
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 + UDP layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- --+
| Minimum length RTP Header (see [RFC3550]) |
+-- --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TSoP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TSoP Packet Format for an IPv4/IPv6 PSN
with UDP PW Demultiplexing
Manhoudt et al. Expires December 16, 2012 [Page 13]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
4.3.2. Usage and Structure of the TSoP Control Word
The purpose of the TSoP control word is to allow:
1. Detection of packet loss or misordering
2. Differentiation between PSN and attachment circuit problems as a
cause for outage of the emulated service
3. Signaling of faults detected at the PW egress to the PW ingress
The structure of the TSoP Control Word is in accordance with the
general PW Control Word format specified in [RFC4385]. The TSoP CW
format is shown in Figure 7 below. This TSoP Control Word MUST be
present in each TSoP PW packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. Structure of the TSoP Control Word
The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be
set to zero unless they are being used to indicate the start of an
Associated Channel Header (ACH). An ACH is needed if the state of
the TSoP PW is being monitored using Virtual Circuit Connectivity
Verification [RFC5085] or in case OAM functionality according to
[RFC6371] is added.
L (bit 4) - If this bit is set, it indicates that the STM-N data
ingressing in the PSN-bound IWF is currently experiencing a fault
condition. Once set, if the fault is rectified, the L-bit MUST be
cleared. For each frame that is transmitted with L-bit = 1, the
PSN-bound IWF MUST insert such an amount of substitution data in
the TSoP payload field that the TSoP frame length, as it is
during normal operation, is maintained. The CE-bound IWF MUST
play out an amount of G-AIS data corresponding to the original
TSoP Payload Field for each received packet with the L-bit set.
Note: This document does not prescribe exactly which STM-N fault
conditions are to be treated as invalidating the payload carried
in the TSoP packets. An example of such a fault condition would
be LOS.
R (bit 5) - If this bit is set by the PSN-bound IWF, it indicates
that its local CE-bound IWF is in the LOPS state, i.e., it has
lost a preconfigured number of consecutive packets. The R-bit
MUST be cleared by the PSN-bound IWF once its local CE-bound IWF
Manhoudt et al. Expires December 16, 2012 [Page 14]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
has exited the LOPS state, i.e., has received a preconfigured
number of consecutive packets. See also section 6.2.2.
RSV (bits 6 to 7) - This field MUST be set to 0 by the PSN-bound IWF
and MUST be ignored by the CE-bound IWF. RSV is reserved.
FRG (bits 8 to 9) - This field MUST be set to 0 by the PSN-bound IWF
and MUST be ignored by the CE-bound IWF. FRG is fragmentation;
see [RFC4623].
LEN (bits 10 to 15) - This field MAY be used to carry the length of
the TSoP packet (defined as the length of the TSoP Encapsulation
Header + TSoP Payload Field) if it is less than 64 octets, and
MUST be set to zero otherwise. When the LEN field is set to 0,
the preconfigured size of the TSoP packet payload MUST be assumed
to be as described in Section 5, and if the actual packet size is
inconsistent with this length, the packet MUST be considered
malformed.
Sequence number (bits 16 to 31) - This field is used to enable the
common PW sequencing function as well as detection of lost
packets. It MUST be generated in accordance with the rules
defined in Section 5.1 of [RFC3550] for the RTP sequence number:
o Its space is a 16-bit unsigned circular space
o Its initial value SHOULD be random (unpredictable).
It MUST be incremented with each TSoP data packet sent in the
specific PW.
4.3.3. Usage of the RTP Header
A minimum length RTP Header as specified in [RFC3550] MUST be
included in the TSoP Encapsulation Header. The reason for mandating
the insertion of an RTP Header by the PSN-bound IWF is that it is
expected that in most cases the CE-bound IWF will need to use the
contained timestamps to be able to recover a clock signal of
sufficient quality. By avoiding to make the presence of RTP Headers
subject to configuration, the design of the of the CE-bound IWF can
be simplified and another potential source of errors during
commissioning is eliminated.
The RTP Header fields in the list below (see also figure 8) MUST have
the following specific values:
V (version) = 2
P (padding) = 0
X (header extension) = 0
Manhoudt et al. Expires December 16, 2012 [Page 15]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
CC (CSRC count) = 0
M (marker) = 0
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. Structure of the RTP Header field
The PT (payload type) field is used as follows:
1. 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.
2. The PSN-bound IWF MUST set the PT field in the RTP header to the
allocated value.
3. The CE-bound IWF MAY use the received value to detect malformed
packets.
The sequence number MUST be the same as the sequence number in the
TSoP control word.
The RTP timestamps are used for carrying timing information over the
network. Their values MUST be generated in accordance with the rules
established in [RFC3550].
A TSoP implementation MUST support RTP timestamping at the PW ingress
with a nominal clock frequency of 25 MHz. This is also the default
value. Other clock frequencies MAY be supported to generate the RTP
Timestamps. Selection of the applicable clock frequency is done
during commissioning of the PW that carries the emulated STM-N
service.
The SSRC (synchronization source) value in the RTP header MAY be used
for detection of misconnections, i.e., incorrect interconnection of
attachment circuits. In case this option is not used, this field
should contain an all zero pattern.
The usage of the options associated with the RTP Header (the
timestamping clock frequency, selected PT and SSRC values) MUST be
aligned between the two TSoP IWFs during Pseudowire commissioning.
Manhoudt et al. Expires December 16, 2012 [Page 16]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
5. TSoP Payload Field
In order to facilitate handling of packet loss in the PSN, all
packets belonging to a given TSoP PW are REQUIRED to carry a fixed
number of octets in its TSoP Payload Field.
The TSoP Payload Field length MUST be defined during PW
commissioning, MUST be the same for both directions of the PW, and
MUST remain unchanged for the lifetime of the PW.
All TSoP implementations MUST be capable of supporting the following
TSoP Payload Field length:
o STM-N (for N = 0, 1, 4, 16 and 64) - 810 octets
Notes:
1. Whatever the selected payload size, TSoP does not assume
alignment to any underlying structure imposed by TDM framing
(octet, frame, or multiframe alignment). The STM-N signal
remains scrambled through the TSoP encapsulation and
decapsulation processes.
2. With a payload size of 810 octets, the STM-N emulated service
over the PSN will have a nominal packet rate of 8000 packets/s
when N = 0 and a nominal packet rate of 24000*N packets/s for
N >= 1.
TSoP uses the following ordering for packetization of the TDM data:
o The order of the payload octets corresponds to their order on
the attachment circuit.
o Consecutive bits coming from the attachment circuit fill each
payload octet starting from most significant bit to least
significant.
6. TSoP Operation
6.1. Common Considerations
Edge-to-edge emulation of an STM-N service using TSoP is only
possible when the two PW attachment circuits are of the same type,
i.e., both are STM-N with equal N.
6.2. IWF Operation
6.2.1. PSN-Bound Direction
Manhoudt et al. Expires December 16, 2012 [Page 17]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
Once the PW is commisioned, the PSN-bound TSoP IWF operates as
follows:
The ingressing STM-N bit-stream is segmented, such that each segment
contains the configured number of payload octets per packet. This
forms the TSoP Payload Field. The STM-N bit-stream MUST NOT be
descrambled before segmentation and packetization for PW transport.
Subsequently, the TSoP Encapsulation Headers are prepended according
to the rules in section 4.3.
Lastly, the PSN/PW Headers are added to the packetized service data,
and, depending on the applicable PSN technology, a Frame Check Sum is
added. The resulting packets are transmitted over the PSN.
6.2.2. CE-Bound Direction
Once the PW is commissioned, the CE-bound TSoP IWF operates as
follows:
Each time a valid TSoP packet is received from the PSN, its sequence
number is checked to determine its relative position in the stream of
received packets. Packets that are received out-of-order MAY be
reordered. Next, the data in the fixed length TSoP payload field of
each packet is written into a (jitter) buffer in the order indicated
by its sequence number. In case data is missing due to a lost packet
or a packet that could not be re-ordered, an equivalent amount of
dummy data (G-AIS pattern) is substituted.
Subsequently, the STM-N stream towards the CE is reconstructed by
playing out the buffer content with a clock that is reconstructed to
have the same average frequency as the STM-N clock at the PW ingress.
In addition, this clock signal must have such properties that the
following requirements can be met:
o A reconstructed SDH-type STM-N signal delivered to an
Attachment Circuit MUST meet [G.825] jitter and wander
requirements, or,
o A reconstructed SONET-type OC-M signal delivered to an
Attachment Circuit MUST meet [GR-253] jitter and wander
requirements.
The size of the buffer in the CE-bound TSoP IWF SHOULD be
configurable to allow accommodation to the PSN specific packet delay
variation.
The CE-bound TSoP IWF SHOULD use the sequence number in the TSoP
Manhoudt et al. Expires December 16, 2012 [Page 18]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
Control Word for detection of lost and misordered packets. The
sequence numbers in the RTP Header MAY be used instead.
Note: A valid sequence number can be always found in bits 16 - 31 of
the first 32-bit word immediately following the PW demultiplexing
header regardless of the specific PSN type, multiplexing method,
location of the RTP header, etc. This approach simplifies
implementations supporting multiple encapsulation types as well as
implementation of multi-segment (MS) PWs using different
encapsulation types in different segments.
The CE-bound TSoP IWF MAY reorder misordered packets. Misordered
packets that can not be reordered MUST be discarded and treated the
same way as lost packets.
The payload of received TSoP packets marked with the L-bit set MUST
be replaced by the equivalent number of bits from the G-AIS pattern.
Likewise, the payload of each lost or malformed (see section 6.3)
TSoP packet MUST be replaced with the equivalent number of bits from
the G-AIS pattern.
Before a TSoP PW has been commissioned and after a PW has been
decommissioned, the IWF MUST play out the G-AIS pattern to its STM-N
attachment circuit.
Once a TSoP PW has been commissioned, the CE-bound IWF begins to
receive TSoP packets and to store their payload in the buffer, but
continues to play out the G-AIS pattern to its TDM attachment
circuit. This intermediate state persists until a preconfigured
degree of filling (for example half of the CE-bound IWF buffer) has
been reached by writing consecutive TSoP packets or until a
preconfigured intermediate state timer (started when the TSoP
commissioning is complete) expires.
Each time an STM-N signal is replaced by a G-AIS signal at the same
nominal bitrate, this signal may start at an arbitrary point in its
repeating 2047-bit sequence. Once the starting point is selected,
the G-AIS signal is sent uninterrupted until the condition that
invoked it has been removed. The frequency of the clock that is used
to generate this G-AIS signal MUST have an accuracy that is better
than +/- 20 ppm relative to the nominal STM-N frequency.
Once the preconfigured amount of the STM-N data has been received,
the CE-bound TSoP IWF enters its normal operational state where it
continues to receive TSoP packets and to store their payload in the
buffer while playing out the contents of the jitter buffer in
accordance with the required clock. In this state, the CE-bound IWF
performs clock recovery, MAY monitor PW defects, and MAY collect PW
Manhoudt et al. Expires December 16, 2012 [Page 19]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
performance monitoring data.
The CE-bound IWF enters the LOPS defect state in case it detects the
loss of a preconfigured number of consecutive packets or if the
intermediate state timer expires before the required amount of TDM
data has been received. While in this state, the local PSN-bound
TSoP IWF SHOULD mark every packet it transmits with the R-bit set.
The CE-bound IWF leaves the LOPS defect state and transits to the
normal state once a preconfigured number of consecutive valid TSoP
packets have been received (successfully reordered packets contribute
to the count of consecutive packets).
The RTP timestamps inserted in each TSoP packet at the PW ingress
allow operation in differential mode provided that both PW ingress
and PW egress IWFs have a local clock that is traceable to a common
timing source.
The use of adaptive mode clocking mode, i.e., recovering the STM-N
clock in the CE-bound IWF by essentially averaging the arrival times
of the TSoP packets from the PSN without using RTP information, is
not recommended for TSoP-based circuit emulation.
6.3. TSoP Defects
In addition to the LOPS state defined above, the CE-bound TSoP IWF
MAY detect the following defects:
o Stray packets
o Malformed packets
o Excessive packet loss rate
o Buffer overrun
o Buffer underrun
o Remote packet loss
Corresponding to each defect is a defect state of the IWF, a
detection criterion that triggers transition from the normal
operation state to the appropriate defect state, and an alarm that
MAY be reported to the management system and thereafter cleared.
Alarms are only reported when the defect state persists for a
preconfigured amount of time (typically 2.5 seconds) and MUST be
cleared after the corresponding defect is undetected for a second
preconfigured amount of time (typically 10 seconds). The trigger and
release times for the various alarms may be independent.
Stray packets MAY be detected by the PSN and PW demultiplexing
layers. The SSRC field in the RTP header MAY be used for this
purpose as well. Stray packets MUST be discarded by the CE-bound
IWF, and their detection MUST NOT affect mechanisms for detection of
Manhoudt et al. Expires December 16, 2012 [Page 20]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
packet loss.
Malformed packets are detected by mismatch between the expected
packet size and the actual packet size inferred from the PSN and PW
demultiplexing layers (taking the value of the L-bit into account).
Differences between the received PT value and the PT value allocated
for this direction of the PW MAY also be used for this purpose.
Malformed, in-order packets MUST be discarded by the CE-bound IWF and
replacement data generated as with lost packets.
Excessive packet loss rate is detected by computing the average
packet loss rate over a configurable amount of time and comparing it
with preconfigured raise and clear thresholds.
Buffer overrun is detected in normal operational state when the
(jitter) buffer of the CE-bound IWF cannot accommodate newly arrived
TSoP packets.
Buffer underrun can detected in normal operational state when the
(jitter) buffer of the CE-bound IWF has insufficient data to maintain
playing out the STM-N signal towards the CE at the recovered clock
rate. In this situation G-AIS MUST be substituted until the buffer
fill has reached its preconfigured degree of filling again.
Remote packet loss is indicated by reception of packets with their
R-bit set.
6.4. TSoP Performance Monitoring
Performance monitoring (PM) parameters are routinely collected for
STM-N services and provide an important maintenance mechanism in SDH
networks. However, STM-N level PM data provides the information over
the performance of the end-to-end STM-N connection, which may extend
well beyond the part in which it is carried over a TSoP Pseudowire.
It may be important to be able to measure the performance of a TSoP
Pseudowire section, which forms a part of the STM-N end-to-end
connection, in isolation. For that reason a set of packet level
counters are specified that can be used to assess the performance of
the TSoP Pseudowire section. Collection of the TSoP PW performance
monitoring data is OPTIONAL and, if implemented, is only performed
after the CE-bound IWF has exited its intermediate state.
The following counters are defined:
ENCAP_TXTOTAL_PKTS - The total number of TSoP packets that is
transmitted towards the PSN by the PSN-bound IWF function. This
includes packets with the L-bit set.
Manhoudt et al. Expires December 16, 2012 [Page 21]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
DECAP_RXTOTAL_PKTS - The total number of TSoP packets that is
received from the PSN by the CE-bound IWF function. This
includes malformed packets, out-of-order packets and packets
with the L-bit set.
DECAP_REORDERED_PKTS - The number of out-of-order TSoP packets
that is received from the PSN by the CE-bound IWF, based on the
received sequence numbers, for which the ordering could be
corrected by the CE-bound IWF.
DECAP_MISSING_PKTS - The number of TSoP packets that did not
arrive at the CE-bound IWF from the PSN, based on the received
sequence numbers.
DECAP_MALFORMED_PKTS - The number of TSoP packets that is received
from the PSN by the CE-bound IWF function which contains one of
the following RTP related errors: TSoP Payload Field length
mismatch, PT-value mismatch (if checked) and/or SSRC mismatch
(if checked).
DECAP_OUTOFORDER_PKTS - The number of out-of-order TSoP packets
that is received from the PSN by the CE-bound IWF, based on the
received sequence numbers, for which the ordering could not be
corrected by the CE-bound IWF.
DECAP_OVERRUN_PKTS - The number of packets that is received from
the PSN that is dropped by the CE-bound IWF due to the fact
that the (jitter) buffer has insufficient capacity to store the
TSoP Payload Field content.
DECAP_UNDERRUN_BITS - The number of bits that is not played out
towards the CE by the CE-bound IWF because the (jitter) buffer
is empty at the moment they need to be played out.
DECAP_PLAYEDOUT_PKTS - The number of packets that has been
successfully played out towards the CE by the CE-bound IWF
containing valid STM-N payload including the packets that have
been received with the L-bit containing substituted data.
Packets which are lost in transmission over the PSN or packets
which discarded by the CE-bound IWF due to some error condition
are not counted.
Note that packets with the L-bit set are considered normal data from
the perspective of TSoP Pseudowire Performance Monitoring, since in
such cases the location of the fault is before the signal ingresses
the PSN-bound IWF, so outside the scope of the TSoP PW.
Manhoudt et al. Expires December 16, 2012 [Page 22]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
7. Quality of Service (QoS) Issues
TSoP SHOULD employ existing QoS capabilities of the underlying PSN.
If the PSN providing connectivity between PE devices is
Diffserv-enabled and provides a PDB [RFC3086] that guarantees low
jitter and low loss, the TSoP 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).
If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212]
with the appropriate bandwidth reservation SHOULD be used in order to
provide a bandwidth guarantee equal or greater than that of the
aggregate TDM traffic.
8. Congestion Control
As explained in [RFC3985], the PSN carrying the PW may be subject to
congestion. TSoP PWs represent inelastic constant bit-rate (CBR)
flows and cannot respond to congestion in a TCP-friendly manner
prescribed by [RFC2914], although the percentage of total bandwidth
they consume remains constant.
Unless appropriate precautions are taken, undiminished demand of
bandwidth by TSoP PWs can contribute to network congestion that may
impact network control protocols.
Whenever possible, TSoP PWs SHOULD be carried across traffic-
engineered PSNs that provide either bandwidth reservation and
admission control or forwarding prioritization and boundary traffic
conditioning mechanisms. IntServ-enabled domains supporting
Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains
[RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide
examples of such PSNs. Such mechanisms will negate, to some degree,
the effect of the TSoP PWs on the neighboring streams. In order to
facilitate boundary traffic conditioning of TSoP traffic over IP
PSNs, the TSoP IP packets SHOULD NOT use the DiffServ Code Point
(DSCP) value reserved for the Default Per-Hop Behavior (PHB)
[RFC2474].
If TSoP PWs run over a PSN providing best-effort service, they SHOULD
monitor packet loss in order to detect "severe congestion". If such
a condition is detected, a TSoP PW SHOULD shut down bi-directionally
for some period of time as described in Section 6.5 of [RFC3985].
Note that:
1. The TSoP IWF can inherently provide packet loss measurement since
Manhoudt et al. Expires December 16, 2012 [Page 23]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
the expected rate of arrival of TSoP packets is fixed and known
2. The results of the TSoP packet loss measurement may not be a
reliable indication of presence or absence of severe congestion if
the PSN provides enhanced delivery. For example:
a) If TSoP traffic takes precedence over non-TSoP traffic, severe
congestion can develop without significant TSoP packet loss.
b) If non-TSoP traffic takes precedence over TSoP traffic, TSoP
may experience substantial packet loss due to a short-term
burst of high-priority traffic.
3. The STM-N services emulated by the TSoP PWs have high availability
objectives (see [G.829]) that MUST be taken into account when
deciding on temporary shutdown of TSoP PWs.
This specification does not define the exact criteria for detecting
"severe congestion" using the TSoP packet loss rate or the specific
methods for bi-directional shutdown the TSoP PWs (when such severe
congestion has been detected) and their subsequent re-start after a
suitable delay. This is left for further study. However, the
following considerations may be used as guidelines for implementing
the TSoP severe congestion shutdown mechanism:
1. If the TSoP PW has been set up using either PWE3 control protocol
[RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures
of these protocols SHOULD be used.
2. If one of the TSoP PW end points stops transmission of packets for
a sufficiently long period, its peer (observing 100% packet loss)
will necessarily detect "severe congestion" and also stop
transmission, thus achieving bi-directional PW shutdown.
9. Security Considerations
TSoP does not enhance or detract from the security performance of the
underlying PSN; rather, it relies upon the PSN mechanisms for
encryption, integrity, and authentication whenever required.
TSoP PWs share susceptibility to a number of Pseudowire layer attacks
and will use whatever mechanisms for confidentiality, integrity, and
authentication are developed for general PWs. These methods are
beyond the scope of this document.
Although TSoP PWs MUST employ an RTP header to achieve an explicit
transfer of timing information, SRTP (see [RFC3711]) mechanisms are
NOT RECOMMENDED as a substitute for PW layer security.
Manhoudt et al. Expires December 16, 2012 [Page 24]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
Misconnection detection capabilities of TSoP increase its resilience
to misconfiguration.
Random initialization of sequence numbers, in both the control word
and the optional RTP header, makes known-plaintext attacks on
encrypted TSoP PWs more difficult. Encryption of PWs is beyond the
scope of this document.
10. Applicability Statements
TSoP is an encapsulation layer intended for carrying SDH STM-N
circuits over the PSN in a structure-agnostic and fully transparent
fashion.
TSoP fully complies with the principle of minimal intervention,
minimizing overhead and computational power required for
encapsulation.
TSoP provides sequencing and synchronization functions needed for
emulation of STM-N bit-streams, including detection of lost or
misordered packets and perform the appropriate compensation.
Furthermore, explicit timing information is provided by the presence
of an RTP timestamp in each TSoP packet.
STM-N bit-streams carried over TSoP PWs may experience delays
exceeding those typical of native SDH networks. These delays include
the TSoP packetization delay, edge-to-edge delay of the underlying
PSN, and the delay added by the jitter buffer. It is recommended to
estimate both delay and delay variation prior to setup of a TSoP PW.
TSoP carries STM-N streams over PSN in their entirety, including any
control plane data contained within the data. Consequently, the
emulated STM-N services are sensitive to the PSN packet loss.
Appropriate generation of replacement data can be used to prevent
shutting down the CE STM-N interface due to occasional packet loss.
Other effects of packet loss on this interface (e.g., errored blocks)
cannot be prevented.
TSoP provides for effective fault isolation by forwarding the local
attachment circuit failure indications to the remote attachment
circuit.
TSoP provides for a carrier-independent ability to detect
misconnections and malformed packets via the PT and SSRC fields in
the RTP Header. This feature increases resilience of the emulated
service to misconfiguration.
Being a constant bit rate (CBR) service, TSoP cannot provide TCP
Manhoudt et al. Expires December 16, 2012 [Page 25]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
friendly behavior under network congestion.
Faithfulness of a TSoP PW may be increased by exploiting QoS features
of the underlying PSN.
TSoP does not provide any mechanisms for protection against PSN
outages, and hence its resilience to such outages is limited.
However, lost-packet replacement and packet reordering mechanisms
increase resilience of the emulated service to fast PSN rerouting
events.
11. IANA Considerations
IANA is requested to assign a new MPLS Pseudowire (PW) type for the
following TSoP encapsulated services:
PW type Description Reference
-------- -------------- ----------
0x0020 STM-0 or OC-1 RFC XXXX
0x0021 STM-1 or OC-3 RFC XXXX
0x0022 STM-4 or OC-12 RFC XXXX
0x0023 STM-16 or OC-48 RFC XXXX
0x0024 STM-64 or OC-192 RFC XXXX
The above value is suggested as the next available value and has been
reserved for this purpose by IANA.
RFC Editor: Please replace RFC XXXX above with the RFC number of this
document and remove this note.
12. Acknowledgements
The authors of this document are much indebted to the authors of
[RFC4553]. This latter RFC has been used as a template and example
for the current document. Moreover, many paragraphs and sentences
have been copied from this RFC without alteration or with only slight
modification into the current document.
Furthermore, we thank Zhu Bao, Jeff Towne, Willem van den Bosch and
Matthew Bocci for their valuable feedback.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Manhoudt et al. Expires December 16, 2012 [Page 26]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[G.707] ITU-T Recommendation G.707/Y.1322 (01/2007) - Network node
interface for the synchronous digital hierarchy (SDH)
[G.783] ITU-T Recommendation G.783 (03/2006) - Characteristics of
synchronous digital hierarchy (SDH) equipment functional
blocks
[O.150] ITU-T Recommendation O.150 (05/1996) - General
requirements for instrumentation for performance
measurement on digital transmission equipment
[G.825] ITU-T Recommendation G.825 (03/2000) - The control of
jitter and wander within digital networks which are based
on the synchronous digital hierarchy (SDH)
[GR-253] Telcordia GR-253-CORE - Synchronous Optical Network
(SONET) Transport Systems: Common Generic Criteria
(September 2000)
13.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed.,
"Requirements for Pseudo-Wire Emulation Edge-to-Edge
(PWE3)", RFC 3916, September 2004.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, March 2005.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, 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.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
Manhoudt et al. Expires December 16, 2012 [Page 27]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, June 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)",
RFC 4842, April 2007.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed.,
"Requirements for Multi-Segment Pseudowire Emulation Edge-
to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5604] Nicklass, O., "Managed Objects for Time Division
Multiplexing (TDM) over Packet Switched Networks (PSNs)",
RFC 5604, July 2009.
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, September 2011.
[G.709] ITU-T Recommendation G.709/Y.1331 (12/2009) - Interfaces
for the Optical Transport Network (OTN)
[G.829] ITU-T Recommendation G.829 (12/2002) - Error performance
events for SDH multiplex and regenerator sections
[802.1Q] IEEE Std. 802.1Q-2011, "Media Access Control (MAC) Bridges
and Virtual Bridge Local Area Networks", 31 August 2011
[MEF 8] Metro Ethernet Forum - Implementation Agreement for the
Emulation of PDH Circuits over Metro Ethernet Networks
(October 2004)
[RTP-TYPE] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-
parameters>
Manhoudt et al. Expires December 16, 2012 [Page 28]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
Appendix A. Parameters to be configured to set up a TSoP PW
The following parameters of the TSoP 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 set-up protocols:
1. Type of attachment circuit, i.e., the value of N of the STM-N
signal, which corresponds to a bit rate as mentioned in section 3.
2. Payload size, i.e., the (constant) number of octets that is
transmitted in the TSoP Payload Field of each TSoP packet. The
default value is 810 octets.
3. Timestamping clock frequency: 25 MHz (default) or an alternative
value.
4. The configurability of the following parameters (see section
6.2.2) governing the behavior of the CE-bound IWF buffer is
optional:
a) The maximum amount of payload data that may be stored in the
CE-bound IWF payload buffer
b) The desired degree of filling of the CE-bound IWF buffer in
steady state (typically 50% of the configured buffer size)
c) The "intermediate state" timer, i.e., the maximum amount of
time that the CE-bound IWF waits before after the first TSoP
packet has been received, before it starts to play out data
from the buffer towards the CE
5. The content of the following RTP header fields must be provided by
the user:
a) The 7-bit RTP Payload Type (PT) value; any value can be
assigned to be used with TSoP PWs. Default is an all zero
pattern.
b) The 32-bit Synchronization Source (SSRC) value. Default is an
all zero pattern.
6. The order of the RTP Header and TSoP-CW Header must be defined.
This may be derived from the applied PSN transport technology, see
section 4.3
7. The number of TSoP packets that must be missed consecutively
before the CE-bound IWF enters the LOPS defect state (default 10)
and the number of TSoP packets that must be received consecutively
Manhoudt et al. Expires December 16, 2012 [Page 29]
INTERNET DRAFT Transparent SDH/SONET over Packet July 09, 2012
to clear the LOPS defect state (default 2). See section 4.3.2 and
[RFC5604]
8. To support the optional excessive packet loss event by the
CE-bound IWF, the following parameters must be configured:
a) The length of the observation period for detecting excessive
packet loss. Default value is 10 s.
b) The minimum number of lost packets that is to be detected in
the observation interval before an excessive packet loss alarm
is raised. Default value is 30% of the expected packets.
c) The maximum number of lost packets that is to be detected in
the observation interval to clear an excessive packet loss
alarm. Default value is 1% of the expected packets.
Authors' Addresses
Gert Manhoudt
AimValley B.V
Utrechtseweg 38
1213 TV Hilversum
The Netherlands
E-mail: gmanhoudt@aimvalley.nl
Stephan Roullot
Alcatel-Lucent Centre de Villarceaux
Route de Villejust
91620 Nozay
France
E-mail: stephan.roullot@alcatel-lucent.com
Peter Roberts
Alcatel-Lucent
600 March Road
Kanata, Ontario, K2K 2E6
Canada
E-mail: peter.roberts@alcatel-lucent.com
Manhoudt et al. Expires December 16, 2012 [Page 30]