PWE3 Working Group Andrew G. Malis
Internet Draft Tellabs, Inc.
Expiration Date: April 2004
Prayson Pate
Overture Networks, Inc.
Ron Cohen (Editor)
Lycium Networks, Inc.
David Zelig
Corrigent Systems
October 2003
SONET/SDH Circuit Emulation over Packet (CEP)
draft-ietf-pwe3-sonet-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The generic requirements and architecture for Pseudo Wire Emulation
Edge-to-Edge (PWE3) have been described in [PWE3-REQ] and [PWE3-
ARCH]. Additional requirements for emulation of SONET/SDH and
lower-rate TDM circuits has been defined in [PWE3-TDM-REQ].
This draft provides encapsulation formats and semantics for
emulating SONET/SDH circuits and services over a packet-switched
network (PSN).
pwe3-sonet Expires April 2004 [Page 1]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Co-Authors
The following individuals are co-authors of this document. Tom
Johnson from Litchfield Communication did most of the editing work
for pre WG versions of the SONET SPE work up to version 01 of this
document.
Craig White Level3 Communications
Ed Hallman Litchfield Communications
Jeremy Brayley Laurel Networks
Jim Boyle Protocol Driven Networks
John Shirron Laurel Networks
Luca Martini Level3 Communications
Marlene Drost Litchfield Communications
Steve Vogelsang Laurel Networks
Tom Johnson (Editor) Litchfield Communications
Ken Hsu Tellabs
Table of Contents
1 CONVENTIONS USED IN THIS DOCUMENT................................3
2 ACRONYMS.........................................................4
3 SCOPE............................................................5
4 CEP ENCAPSULATION FORMAT.........................................6
4.1 SONET/SDH Fragment..............................................7
4.2 CEP Header......................................................8
4.3 RTP Header.....................................................10
4.4 PSN Encapsulation..............................................11
5 CEP OPERATION...................................................14
5.1 CEP Packetizer and De-Packetizer...............................15
5.2 Packet Synchronization.........................................16
6 SONET/SDH MAINTENANCE SIGNALS...................................17
6.1 SONET/SDH to PSN...............................................17
6.2 PSN to SONET/SDH...............................................19
7 SONET/SDH TRANSPORT TIMING......................................21
8 SONET/SDH POINTER MANAGEMENT....................................21
8.1 Explicit Pointer Adjustment Relay (EPAR).......................21
8.2 Adaptive Pointer Management (APM)..............................22
9 CEP PERFORMANCE MONITORS........................................23
9.1 Near-End Performance Monitors..................................23
9.2 Far-End Performance Monitors...................................24
10 PAYLOAD COMPRESSION OPTIONS....................................25
10.1 Dynamic Bandwidth Allocation..................................25
10.2 Service-Specific Payload Formats..............................27
11 SIGNALING OF CEP PW............................................35
11.1 CEP payload bytes.............................................35
11.2 CEP/TDM bit rate..............................................35
11.3 CEP options...................................................36
12 OPEN ISSUES....................................................37
13 SECURITY CONSIDERATIONS........................................37
14 INTELLECTUAL PROPERTY DISCLAIMER...............................37
15 REFERENCES.....................................................38
16 AUTHORS ADDRESSES.............................................40
pwe3-sonet Expires December 2003 [Page 2]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
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].
2 Acronyms
ADM Add Drop Multiplexer
AIS Alarm Indication Signal
AU-n Administrative Unit-n (SDH)
AUG Administrative Unit Group (SDH)
BIP Bit Interleaved Parity
BITS Building Integrated Timing Supply
CEP Circuit Emulation over Packet
DBA Dynamic Bandwidth Allocation - see [CEP-SPE]
EBM Equipped Bit Mask
LOF Loss of Frame
LOS Loss of Signal
LTE Line Terminating Equipment
PSN Packet Switched Network
POH Path Overhead
PTE Path Terminating Equipment
PWE3 Pseudo-Wire Emulation Edge-to-Edge
RDI Remote Defect Indication
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
STM-n Synchronous Transport Module-n (SDH)
STS-n Synchronous Transport Signal-n (SONET)
TDM Time Division Multiplexing
TOH Transport Overhead
pwe3-sonet Expires December 2003 [Page 3]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
TU-n Tributary Unit-n (SDH)
TUG-n Tributary Unit Group-n (SDH)
VC-n Virtual Container-n (SDH)
VT Virtual Tributary (SONET)
VTG Virtual Tributary Group (SONET)
pwe3-sonet Expires December 2003 [Page 4]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
3 Scope
This document describes how to emulate the following digital signals
over a packet switched network:
1. Synchronous Payload Envelope (SPE): STS-1/VC-3, STS-3c/VC-4, STS-
12c/VC-4-4c, STS-48c/VC-4-16c, STS-192c/VC-4-64c.
2. Virtual Tributary (VT): VT1.5/VC-11, VT2/VC-12, VT3, VT6/VC-2
For the remainder of this document, these constructs will be
referred to as SONET/SDH channels.
Although this document currently covers up to OC-192c/VC-4-64c,
future revision MAY address higher rates.
pwe3-sonet Expires December 2003 [Page 5]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4 CEP Encapsulation Format
In order to transport SONET/SDH circuits through a packet-oriented
network, the SPE (or VT) is broken into fragments, and a CEP Header
is pre-pended to each fragment. The resulting packet is
encapsulated in RTP for transmission over an arbitrary PSN. The RTP
header location differs for MPLS PSNs. See section 4.4.2 for
details.
Under certain circumstances the RTP header may be suppressed to
conserve network bandwidth. See section 4.4.4 for details.
The basic CEP packet appears in Figure 1.
+-----------------------------------+
| PSN and Multiplexing Layer |
| Headers |
+-----------------------------------+
| RTP Header |
| (RFC1889) |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| |
| |
| SONET/SDH |
| Fragment |
| |
| |
+-----------------------------------+
Figure 1 - Basic CEP Packet
pwe3-sonet Expires December 2003 [Page 6]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.1 SONET/SDH Fragment
The SONET/SDH Fragments MUST be byte aligned with the SONET/SDH SPE
(or VT).
The first bit received from each byte of the SONET/SDH MUST be the
Most Significant Bit of each byte in the SONET/SDH fragment.
SONET/SDH bytes are placed into the SONET/SDH fragment in the same
order in which they are received.
SONET/SDH optical interfaces use binary coding and therefore are
scrambled prior to transmission to insure an adequate number of
transitions. For clarity, this scrambling will be referred to as
physical layer scrambling/descrambling.
In addition, many payload formats (such as for ATM and HDLC) include
an additional layer of scrambling to provide protection against
transition density violations within the SPEs. This function will
be referred to as payload scrambling/descrambling.
CEP assumes that physical layer scrambling/descrambling occurs as
part of the SONET/SDH section/line termination Native Service
Processing (NSP) functions.
However, CEP makes no assumption about payload scrambling. The
SONET/SDH fragments MUST be constructed without knowledge or
processing of any incidental payload scrambling.
CEP implementations MUST include the H3 (or V3) byte in the
SONET/SDH fragment during negative pointer adjustment events, and
MUST remove the stuff-byte from the SONET/SDH fragment during
positive pointer adjustment events.
All CEP SPE Implementations MUST support a packet size of 783 Bytes
and MAY support other packet sizes.
VT emulation implementations MUST support payload size of full VT
super-frame, and MAY support 1/2 and 1/4 VT super-frame payload
sizes.
OPTIONAL SONET/SDH Fragment formats have been defined to reduce the
bandwidth requirements of the emulated SONET/SDH circuits under
certain conditions. These OPTIONAL Formats are included in Appendix
B.
pwe3-sonet Expires December 2003 [Page 7]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.2 CEP Header
The CEP Header supports a basic and extended mode. The Basic CEP
Header provides the minimum functionality necessary to accurately
emulate a TDM SONET over a PSN if a common reference is available at
both ends of the PW.
Enhanced functionality and commonality with other real-time Internet
applications is provided by RTP encapsulation.
Bit 0 of the first 32-bit CEP header indicates whether or not the
extended header is present. When this bit is 0, then no extended
header is present. When this bit is 1, then an extended header is
present. Extended headers are utilized for the some of the OPTIONAL
SONET/SDH fragment formats described in Appendix B.
The Basic CEP header has the following format:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - Basic CEP Header Format
The above fields are defined as follows:
R bit: CEP-RDI. This bit is set to one to signal to the remote CEP
function that a loss of packet synchronization has occurred.
D bit: Signals DBA Mode. MUST be set to zero for Normal Operation.
MUST be set to one if CEP is currently in DBA mode. DBA is an
optional mode during which trivial payloads are not transmitted into
the packet network. See Table 1 and section 10.1 for further
details.
The N and P bits: MAY be used to explicitly relay negative and
positive pointer adjustment events across the PSN. They are also
used to relay SONET/SDH maintenance signals such as AIS-P/V. See
Table 1 and section 8.1 for more details.
pwe3-sonet Expires December 2003 [Page 8]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
+---+---+---+----------------------------------------------+
| D | N | P | Interpretation |
+---+---+---+----------------------------------------------+
| 0 | 0 | 0 | Normal Mode No Ptr Adjustment |
| 0 | 0 | 1 | Normal Mode Positive Ptr Adjustment |
| 0 | 1 | 0 | Normal Mode Negative Ptr Adjustment |
| 0 | 1 | 1 | Normal Mode AIS-P/V |
| | | | |
| 1 | 0 | 0 | DBA Mode STS Unequipped |
| 1 | 0 | 1 | DBA Mode STS Unequipped Pos Ptr Adj |
| 1 | 1 | 0 | DBA Mode STS Unequipped Neg Ptr Adj |
| 1 | 1 | 1 | DBA Mode AIS-P/V |
+---+---+---+----------------------------------------------+
Table 1 - Interpretation of D, N, and P bits
Sequence Number[0:13]: This is a packet sequence number, which MUST
continuously cycle from 0 to 0x3FFF. It is generated and processed
in accordance with the rules established in [RFC1889]. When the RTP
header is used, this sequence number MUST match the LSBs of the RTP
sequence Number.
Structure Pointer[0:12]: The Structure Pointer MUST contain the
offset of the first byte of the payload structure. For SPE
emulation, the structure pointer locates the J1 byte within the CEP
SONET/SDH Fragment. For VT emulation the structure pointer locates
the V5 byte within the SONET/SDH fragment. The value is from 0 to
0x1FFE, where 0 means the first byte after the CEP header. The
Structure Pointer MUST be set to 0x1FFF if a packet does not carry
the J1 (or V5) byte.
pwe3-sonet Expires December 2003 [Page 9]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.3 RTP Header
CEP uses the fixed RTP Header as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 3 - RTP Header
V : (version) always set to 2
P : (padding) always set to 0
X : (header extension) always set to 0
CC: (CSRC count) always set to 0
M : (marker) set to 0 for CEP packets.
PT: (payload type) used to identify packets carrying the packetized
SONET/SDH data. One PT value should be allocated from the range of
dynamic values (see [RTP-TYPES]) for every CEP PW. Allocation is
done during the PW setup and MUST be the same for both PW
directions. The PE at the PW ingress MUST set the PT value in the
RTP header to the allocated value.
Sequence Number : used primarily to provide the common PW sequencing
function as well as detection of lost packets. It is generated and
processed in accordance with the rules established in [RFC1889].
Timestamp : used primarily for carrying timing information over the
network. Their values are used in accordance with the rules
established in [RFC1889]. Frequency of the clock used for
generating timestamps MUST be 19.44 MHz based on a local reference.
SSRC : (synchronization source) MAY be used for detection of
misconnections.
pwe3-sonet Expires December 2003 [Page 10]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.4 PSN Encapsulation
In principle, CEP packets can be carried over any packet-oriented
network. The following sections describe specifically how CEP
packets MUST be encapsulated for carriage over MPLS or IP networks.
4.4.1 IP Encapsulation
CEP uses the standard IP/UDP/RTP encapsulation scheme as shown
below. The UDP destination port MUST be used to De-multiplex
individual SONET channels. RTP header may be suppressed to conserve
network bandwidth. (See section 4.4.4 for details).
+-----------------------------------+
| |
| IPv6/v4 Header |
| |
+-----------------------------------+
| UDP Header |
+-----------------------------------+
| RTP Header |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| |
| |
| SONET/SDH Fragment |
| |
| |
+-----------------------------------+
Figure 4 - IP Transport Encapsulation
pwe3-sonet Expires December 2003 [Page 11]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.4.2 MPLS Encapsulation
Figure 5 describes CEP encapsulation over an MPLS network. To
transport a CEP packet over an MPLS network, an MPLS label-stack
MUST be pushed on top of the CEP packet. The bottom label in the
MPLS label stack MUST be used to de-multiplex individual SONET
channels. In keeping with the conventions used in [PWE3-CONTROL],
this de-multiplexing label is referred to as the PW Label and the
upper labels are referred to as Tunnel Labels.
To allow accurate packet inspection in an MPLS PSN, and/or to
operate correctly over MPLS networks that have deployed equal-cost
multiple-path load-balancing (ECMP), a PW packet should not alias an
IP packet. A PW Protocol Identifier (PID) field is used in these
scenarios as a PSN convergence layer [PWE3-ARCH]. The PW PID field
MAY be suppressed in MPLS networks were IP aliasing is not a
problem.
RTP header immediately follows the PW CEP header. RTP header MAY be
suppressed to conserve network bandwidth. (See section 4.4.4 for
details).
+-----------------------------------+
| One or more MPLS Tunnel Labels |
+-----------------------------------+
| PW Label |
+-----------------------------------+
| PW PID |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| RTP Header |
+-----------------------------------+
| |
| |
| SONET/SDH Fragment |
| |
| |
+-----------------------------------+
Figure 5 - MPLS Transport Encapsulation
pwe3-sonet Expires December 2003 [Page 12]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
4.4.3 L2TPv3 Encapsulation
Figure 6 describes CEP encapsulation over Layer 2 Tunneling Protocol
version 3 [L2TPv3]. RTP header may be suppressed to conserve network
bandwidth. (See section 4.4.4 for details). The L2TPv3 header MUST
be used to de-multiplex individual SONET channels.
+-----------------------------------+
| L2TPv3 Header |
+-----------------------------------+
| RTP Header |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| |
| |
| SONET/SDH Fragment |
| |
| |
+-----------------------------------+
Figure 6 L2TPv3 Transport Encapsulation
pwe3-sonet Expires December 2003 [Page 13]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
CEP uses the L2TPv3 header as defined below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (Long) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 7 L2TPv3 Header
Session ID: Used to de-multiplex individual SONET channels
Cookie: Optional 0/32/64 bit field. MAY be used for detection of
misconnections.
CEP by default suppress the Cookie field. Use of the Cookie field
and its length may be statically configured or signaled using
[L2TPv3]
4.4.4 RTP Header Suppression
In addition to normal RTP header compression mechanisms as described
in [RFC2508] and [RFC3095], an additional option may be used in CEP
which suppresses transmission of the RTP header altogether.
This mode may be used when both PEs support RTP Header Suppression.
The choice to utilize RTP Header Suppression may be statically
configured using [CEM-MIB], or signaled using a PW maintenance
protocol such as [PWE3-CONTROL].
5 CEP operation
CEP MUST support a normal mode of operation and MAY support
additional bandwidth conserving modes described in section 1
.0.
During normal operation, SONET/SDH payloads are fragmented, pre-
pended with the appropriate headers and then transmitted into the
packet network.
pwe3-sonet Expires December 2003 [Page 14]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
5.1 CEP Packetizer and De-Packetizer
As with all adaptation functions, CEP has two distinct components:
adapting TDM SONET/SDH into a CEP packet stream, and converting the
CEP packet stream back into a TDM SONET/SDH. The first function
will be referred to as CEP Packetizer and the second as CEP De-
Packetizer. This terminology is illustrated in Figure 8.
+------------+ +---------------+
| | | |
SONET --> | CEP | --> PSN --> | CEP | --> SONET
SDH | Packetizer | | De-Packetizer | SDH
| | | |
+------------+ +---------------+
Figure 8 - CEP Terminology
Note: the CEP de-packetizer requires a buffering mechanism to
account for delay variation in the CEP packet stream. This
buffering mechanism will be generically referred to as the CEP
jitter buffer.
During normal operation, the CEP packetizer will receive a fixed
rate byte stream from a SONET/SDH interface. When a packets worth
of data has been received from a SONET/SDH channel, the necessary
headers are pre-pended to the SPE fragment and the resulting CEP
packet is transmitted into the packet network. Because all CEP
packets associated with a specific SONET/SDH channel will have the
same length, the transmission of CEP packets for that channel SHOULD
occur at regular intervals.
At the far end of the packet network, the CEP de-packetizer will
receive packets into a jitter buffer and then play out the received
byte stream at a fixed rate onto the corresponding SONET/SDH
channel. The jitter buffer SHOULD be adjustable in length to
account for varying network delay behavior. The receive packet rate
from the packet network should be exactly balanced by the
transmission rate onto the SONET/SDH channel, on average. The time
over which this average is taken corresponds to the depth of the
jitter buffer for a specific CEP channel.
The RTP sequence numbers provide a mechanism to detect lost and/or
mis-ordered packets. The sequence number in the CEP header MUST be
used when transmission of the RTP header is suppressed (see 4.4.4
for details). The CEP de-packetizer MUST detect lost or miss-
ordered packets. The CEP de-packetizer SHOULD play out an all ones
pattern (AIS) in place of any dropped packets. The CEP de-
packetizer MAY re-order packets received out of order. If the CEP
de-packetizer does not support re-ordering, it must drop miss-
ordered packets.
pwe3-sonet Expires December 2003 [Page 15]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
5.2 Packet Synchronization
A key component in declaring the state of a CEP service is whether
or not the CEP de-packetizer is in or out of packet synchronization.
The following paragraphs describe how that determination is made.
As discussed in section 6, a CEP de-packetizer MAY or MAY NOT
support re-ordering of miss-ordered packets.
As packets are received from the PSN, they are placed into a jitter
buffer prior to play out on the SONET interface. If a CEP de-
packetizer supports re-ordering, any packet received before its play
out time will still be considered valid.
If a CEP de-packetizer does not support re-ordering, a number of
approaches may be used to minimize the impact of miss-ordered or
lost packets on the final re-assembled SONET stream. For
example, [AAL1] uses a simple state-machine to re-order packets in a
sub-set of possible cases.
However, the final determination as to whether or not to declare
acquisition or loss of packet synchronization MUST be based on the
same criteria regardless of whether an implementation supports or
does not support re-ordering.
Therefore, the determination of acquisition or loss of packet
synchronization is always made at SONET play-out time. During SONET
play-out, the CEP de-packetizer will play received CEP packets onto
the SONET interface. However, if the jitter buffer is empty or the
packet to be played out has not been received, the CEP de-packetizer
will play out an empty packet onto the SONET interface in place of
the unavailable packet.
The acquisition of packet synch is based on the number of sequential
CEP packets that are played onto the SONET interface. Loss of
packet synch is based on the number of sequential 'empty' packets
that are played onto the SONET interface. Specific details of these
two cases are described below.
5.2.1 Acquisition of Packet Synchronization
At startup, a CEP de-packetizer will be out of packet
synchronization by default. To declare packet synchronization at
startup or after a loss of packet synchronization, the CEP de-
packetizer must play-out a configurable number of CEP packets with
sequential sequence numbers towards the SONET interface.
5.2.2 Loss of Packet Synchronization
Once a CEP de-packetizer is in packet sync, it may encounter a set
of events that will cause it to lose packet synchronization.
pwe3-sonet Expires December 2003 [Page 16]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
If the CEP de-packetizer encounters more than a configurable number
of sequential empty packets, the CEP de-packetizer MUST declare loss
of packet synchronization (LOPS) defect.
Loss of Packet Synchronization (LOPS) failure is declared after 2.5
+/- 0.5 seconds of LOPS defect, and cleared after 10 seconds free of
LOPS defect state. The VC is considered down as long as LOPS failure
is declared.
6 SONET/SDH Maintenance Signals
There are several issues that must be considered in the mapping of
maintenance signals between SONET/SDH and a PSN. A description of
how these signals and conditions are mapped between the two domains
is described below.
For clarity, the mappings are split into two groups: SONET/SDH to
PSN, and PSN to SONET/SDH.
The failure mappings guarantee that SONET/SDH indications will be
transferred correctly over the CEP connection, and CEP connection
failures will be correctly propagated to the PATH/VT at the de-
packetizer. This allows coherent failure monitoring, detection and
trouble shooting for a PATH/VT signal crossing both a traditional
SONET/SDH network and packet network.
6.1 SONET/SDH to PSN
The following sections describe how SONET/SDH Maintenance Signals
and Alarm conditions are mapped into a Packet Switched Network.
6.1.1 AIS-P/V Indication
In a SONET/SDH network, SONET Path outages are signaled using
maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P
indicates that the SONET/SDH Path is not currently transmitting
valid end-user data, and the SPE contains all ones. Similarily, AIS-
V indicates that the VT is not currently transmitting valid end-user
data, and the VT contains all ones.
It should be noted that nearly every type of service-affecting
section or line defect would result in an AIS-P/V condition.
The mapping of SONET failures into the PATH/VT layer is considered
part of the NSP function, and is based on the principles in [GR253]
and [G.707]. Should the Section Layer detect a Loss of Signal (LOS)
or Loss of Frame (LOF) condition, it sends AIS-L up to the Line
Layer. If the Line Layer detects AIS-L or Loss of Path (LOP), it
pwe3-sonet Expires December 2003 [Page 17]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
sends AIS-P to the Path Layer. If the Path layer detects AIS-P and
is terminated at the NSP, it sends AIS-V to the VT Layer.
The AIS-P indication is transferred to the CEP packetizer. During
AIS-P, SPE CEP packets are generated as usual. The N and P bits MUST
be set to 11 binary to signal AIS-P explicitly through the packet
network. The D-bit MUST be set to zero to indicate that the SPE is
being carried through the packet network. Normal CEP packets with
the SPE fragment, CEP Header, the Circuit ID Word, and PSN Header
MUST be transmitted into the packet network. The same rules are
followed for VT CEP packets during AIS-V condition.
6.1.2 Unequipped Indication
The declaration of SPE/VT unequipped MUST conform to [GR253].
Unequipped indication is used for DBA bandwidth conserving mode as a
trigger for payload removal.
STS PTE shall detect an STS Path Unequipped (UNEQ-P) defect within
10 ms of the onset of at least five consecutive samples (which may
or may not be consecutive frames) of unequipped STS Signal Labels
(C2 byte). STS PTE shall terminate an UNEQ-P defect within 10 ms of
the onset of at least five consecutive samples (which may or may not
be consecutive frames) of STS Signal Labels that are not unequipped
or all-ones. Similar rules apply to detection and termination of VT
Unequipped (UNEQ-V) defects.
During SPE/VT Unequipped, the N and P bits MUST be interpreted as
usual. The SPE/VT MUST be transmitted into the packet network along
with the appropriate headers, and the D-Bit MUST be set to zero.
If DBA has been enabled for STS SPE Unequipped and the Unequipped is
occurring on the SONET/SDH channel, the D-bit MUST be set to one to
indicate DBA is active. Only the necessary headers are transmitted
into the packet network. The N and P bits MAY be used to signal
pointer adjustments as normal.
6.1.3 CEP-RDI
The CEP function MUST send CEP-RDI towards the packet network during
loss of packet synchronization. This MUST be accomplished by
setting the R bit to one in the CEP header.
pwe3-sonet Expires December 2003 [Page 18]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
6.2 PSN to SONET/SDH
The following sections discuss how the various conditions on the
packet network are converted into SONET/SDH indications.
The SONET/SDH hierarchy combined with CEP is illustrated below.
+----------+
| VT |
+----------+
^ ^
| |
| LOPS
| | +------------+
| +-----| CEP VT PW |
| +------------+
AIS-V
|
+----------+
| PATH |
+----------+
^ ^
| |
| LOPS
| | +------------+
| +-----| CEP SPE PW |
| +------------+
---------------- | -----------------------
^
AIS-P
NSP |
+----------+
| LINE |
+ ---------+
^ ^
| |
AIS-L +------ LOP
|
+----------+
| SECTION |
+----------+
^ ^
| |
LOS LOF
Figure 9 - SONET/SDH and CEP AIS Fault Hierarchy
pwe3-sonet Expires December 2003 [Page 19]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
6.2.1 AIS-P/V Indication
There are several conditions in the packet network that will cause
the CEP de-packetization function to play out an AIS-P/V indication
towards a SONET/SDH channel.
The first of these is the receipt of CEP packets with the N and P
bits set to one. This is an explicit indication of AIS-P being
received at the far-end of the packet network. The CEP de-
packetizer MUST play out one packet's worth of all ones for each
packet received, and MUST set the SONET/SDH Overhead to signal AIS-
P/V as defined in [SONET], [GR253], and [G707].
The second case that will cause a CEP de-packetization function to
play out an AIS-P indication onto a SONET/SDH channel is during loss
of packet synchronization. In this case, the CEP de-packetizer MUST
set the SONET/SDH Overhead to signal AIS-P/V as defined in [SONET],
[GR253], and [G707].
6.2.2 Unequipped Indication
There are several conditions in the packet network that will cause
the CEP function to transmit Unequipped indications onto the
SONET/SDH channel.
The first, which is transparent to CEP, is the receipt of regular
CEP packets that happen to be carrying an SPE that contains the
appropriate Path overhead or VT overhead set to unequipped. This
case does not require any special processing on the part of the CEP
de-packetizer.
The second case is the receipt of CEP packets that have the D-bit
set to one to indicate DBA active and the N and P bits set to 00
binary, 01 binary, or 10 binary to indicate SPE Unequipped with or
without pointer adjustments. The CEP de-packetizer MUST use this
information to transmit a packet of all zeros onto the SONET/SDH
interface, and adjust the payload pointer as necessary.
The third case when a CEP de-packetizer MUST play out an SPE/VT
Unequipped Indication towards the SONET interface is when the
circuit has been de-provisioned.
pwe3-sonet Expires December 2003 [Page 20]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
7 SONET/SDH Transport Timing
It is assumed that the distribution of SONET/SDH Transport timing
information is addressed through external mechanisms such as
Building Integrated Timing System (BITS), Stand Alone
Synchronization Equipment (SASE), Global Positioning System (GPS) or
other such methods, or is addressed through an adaptive timing
recovery algorithm, and is therefore outside of the scope of this
specification.
8 SONET/SDH Pointer Management
A pointer management system is defined as part of the definition of
SONET/SDH. Details on SONET/SDH pointer management can be found in
[SONET], [GR253], and [G707]. If there is a frequency offset
between the frame rate of the transport overhead and that of the
SONET/SDH SPE, then the alignment of the SPE (or VT) will
periodically slip back or advance in time through positive or
negative stuffing.
The emulation of this aspect of SONET networks may be accomplished
using a variety of techniques including (but not limited to)
explicit pointer adjustment relay (EPAR) and adaptive pointer
management (APM).
In any case, the handling of the SPE data by the CEP packetizer is
the same.
During a negative pointer adjustment event, the CEP packetizer MUST
incorporate the H3 (or V3) byte from the SONET/SDH stream into the
CEP packet payload in order with the rest of the SPE. During a
positive pointer adjustment event, the CEP packetizer MUST strip the
stuff byte from the CEP packet payload.
When playing out a negative pointer adjustment event, the
appropriate byte of the CEP payload MUST be placed into the H3 (or
V3) byte of the SONET/SDH stream. When playing out a positive
pointer adjustment, the CEP de-packetizer MUST insert a stuff-byte
into the appropriate position within the SONET/SDH stream.
The details regarding the use of the H3 (and V3) byte and stuff byte
during positive and negative pointer adjustments can be found in
[SONET], [GR253], and [G707].
8.1 Explicit Pointer Adjustment Relay (EPAR)
CEP provides an OPTIONAL mechanism to explicitly relay pointer
adjustment events from one side of the PSN to the other. This
technique will be referred to as Explicit Pointer Adjustment Relay
pwe3-sonet Expires December 2003 [Page 21]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
(EPAR). EPAR is only effective when both ends of the PW have access
to a common timing reference.
The following text only applies to implementations that choose to
implement EPAR. Any CEP implementation that does not support EPAR
MUST either set the N and P bits to zero or utilize them to relay
AIS-P/V and STS/VT Unequipped as shown in table 1.
When working in EPAR mode, it is assumed that a common reference
clock is available for both the de-packetizer and the packetizer.
The CEP service relay the pointer adjustments which represents the
difference between the SPE/VT frequency and the reference clock,
keeping the SPE/VT payload rate equal at the de-packetizer and
packetizer outputs.
The mechanics of EPAR are described below.
For SPE Emulation, the pointer adjustment event MUST be transmitted
in three consecutive packets by the packetizer. The de-packetizer
MUST play out the pointer adjustment event when any one packet with
N/P bit set is received.
The CEP de-packetizer MUST utilize the CEP sequence numbers to
insure that SONET/SDH pointer adjustment events are not played any
more frequently than once per every three CEP packets transmitted by
the remote CEP packetizer.
For VT emulation, a pointer adjustment event MUST be transmitted in
all packets carrying a single VT super-frame, starting from the
packet carrying the V5 byte and not including the packet carrying
the V5 byte of the next VT super-frame. Pointer adjustment events at
the VT and STS-1 levels are mapped to N and P indications. Pointer
adjustments at the VT level are mapped 1:1 to CEP indications, while
SPE pointer indications are mapped according to the ratio of VT/SPE
byte rates.
If both bits are set, then an AIS-P/V event has been detected at the
PW ingress, making the pointer invalid.
When DBA is invoked (i.e. the D-bit = 1), N and P have additional
meanings. See Table 1 and section Appendix C for more details.
8.2 Adaptive Pointer Management (APM)
Another OPTIONAL method that may be used to emulate SONET pointer
management is Adaptive Pointer Management (APM). In basic terms,
APM uses information about the depth of the CEP jitter buffers to
introduce pointer adjustments in the reassembled SONET SPE.
Details about specific APM algorithms are not considered to be
within scope for this document.
pwe3-sonet Expires December 2003 [Page 22]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
9 CEP Performance Monitors
SONET/SDH as defined in [SONET], [GR253], and [G707] includes the
definition of several counters that may be used to monitor the
performance of SONET/SDH services. These counters are referred to
as Performance Monitors.
In order for CEP to be utilized by traditional SONET/SDH network
operators, CEP SHOULD provide similar functionality. To this end,
the following sections describe a number of counters that will
collectively be referred to as CEP Performance Monitors.
9.1 Near-End Performance Monitors
These performance monitors are maintained by the CEP De-Packetizer
during reassembly of the SONET stream.
The performance monitors are based on two types of defects.
Type 1 : missing or dropped packet.
Type 2 : buffer under run, buffer over-run, LOPS, missing packets
above pre-defined, configurable threshold.
The specific performance monitors defined for CEP are as follows:
ES-CEP CEP Errored Seconds
SES-CEP - CEP Severely Errored Seconds
UAS-CEP - CEP Unavailable Seconds
Each second that contain at least one type 1 defect SHALL be
declared as ES-CEP. Each second that contain at least one type 2
defect SHALL be declared as SES-CEP.
UAS-CEP SHALL be declared after configurable number of consecutives
SES-CEP, and cleared after a configurable number of consecutive
seconds without SES-CEP. Default value for each is 10 seconds.
Once unavailability is declared, ES and SES counts SHALL be
inhibited up to the point where the unavailability was started. Once
unavailability is removed, ES that occurred along the X seconds
clearing period SHALL be added to the ES counts.
pwe3-sonet Expires December 2003 [Page 23]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
9.2 Far-End Performance Monitors
These performance monitors provide insight into the CEP De-
packetizer at the far-end of the PSN.
Far end statistics are based on the RDI-CEP bit. CEP-FE defect is
declared when CEP-RDI is set in the incoming CEP packets.
CEP-FE failure declared after 2.5 +/- 0.5 seconds of CEP-FE defect,
and cleared after 10 seconds free of CES-FE defect state. Sending
notification to the OS for CEP-FE failure is local policy.
pwe3-sonet Expires December 2003 [Page 24]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
10 Payload Compression Options
In addition to pure emulation, CEP also offers a number of options
for reducing the total bandwidth utilized by the emulated circuit.
These options fall into two categories: Dynamic Bandwidth Allocation
and Service-Specific Payload Formats.
Dynamic Bandwidth Allocation suppresses transmission of the CEP
payload altogether under certain circumstances such as AIS-P/V and
STS/VT Unequipped. Service-Specific Payload formats reduce
bandwidth by suppressing transmission of portions of the SPE based
on specific knowledge of the SPE payload.
Details on these payload compression options are described in the
following subsections.
10.1 Dynamic Bandwidth Allocation
Dynamic Bandwidth Allocation (DBA) is an OPTIONAL mechanism for
suppressing the transmission of the SPE (or VT) fragment when one of
two trigger conditions are met, AIS-P/V or STS/VT Unequipped.
Implementations that support DBA MUST include a mechanism for
disabling DBA on a channel-by-channel basis to allow for
interoperability with implementations that do not support DBA.
When a DBA trigger is recognized at PW ingress, the CEP packets will
be constructed as shown in figure 10.
Optional padding bytes may be included if the intervening packet
network has a minimum packet size which is less than the DBA packet.
+-----------------------------------+
| PSN and Multiplexing Layer |
| Headers |
+-----------------------------------+
| RTP Header |
| (RFC1889) |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| (Optional) Padding |
+-----------------------------------+
Figure 10 - Basic CEP-DBA Packet
pwe3-sonet Expires December 2003 [Page 25]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
If RTP Header suppression is utilized, the CEP packets will be
constructed as shown in figure 11
+-----------------------------------+
| PSN and Multiplexing Layer |
| Headers |
+-----------------------------------+
| CEP Header |
+-----------------------------------+
| (Optional) Padding |
+-----------------------------------+
Figure 11 - CEP-DBA Packet with RTP Header Suppression
Other than the suppression of the CEP payload, the CEP behavior
during DBA should be equivalent to normal CEP behavior. In
particular, the packet transmission rate during DBA should be
equivalent to the normal packet transmission rate.
pwe3-sonet Expires December 2003 [Page 26]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
10.2 Service-Specific Payload Formats
In addition to the standard payload encapsulations for SPE and VT
transport, several OPTIONAL payload formats have been defined to
provide varying amounts of payload compression depending on the type
and amount of user traffic present within the SPE. These are
described below:
10.2.1 Fractional STS-1 (VC-3) Encapsulation
Fractional STS-1 (VC-3) encapsulation carries only selected set of
VTs within an STS-1 container. This mode is applicable for STS-1
with POH signal label byte C2=2 (VT-structured SPE) and for C2=3
(Locked VT mode). The mapping of VTs into an STS-1 container is
described in section 3.2.4 of [GR253] and the mapping into VC-3 is
defined in section 7.2.4 in [G.707]. The CEP packetizer removes all
fixed column bytes (columns 30 and 59) and all bytes that belong to
the removed VTs. Only STS-1 POH bytes and bytes that belong to the
selected VTs are carried within the payload. The CEP de-packetizer
adds the fixed stuff bytes and generates unequipped VT data
replacing the removed VT bytes.
Figure 12 below describes VT mapping into an STS-1 SPE.
1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87
+--+------------------+-+------------------+-+------------------+
1 |J1| Byte 1 (V1-V4) |R| | | | |R| | | | |
+--+---+---+------+---+-+------------------+-+------------------+
2 |B3|VT | | | |R| | | | |R| | | | |
+--+1.5| | | +-+---+---+------+---+-+------------------+
3 |C2| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
4 |G1| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
5 |F2| | | | |R| | | | |R| | | | |
+--|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|
6 |H4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
7 |Z3| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
8 |Z4| | | | |R| | | | |R| | | | |
+--+ | | | +-+---+---+------+---+-+------------------+
9 |Z5| | | | |R| | | | |R| | | | |
+--+---+---+------+---+-+---+---+------+---+-+------------------+
| | |
+-- Path Overhead +--------------------+-- Fixed Stuffs
Figure 12 - SONET SPE Mapping of VT1.5
pwe3-sonet Expires December 2003 [Page 27]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
The SPE always contains seven interleaved VT groups (VTGs). Each VTG
contains a single type of VT, and each VTG occupies 12 columns (108
bytes) within each SPE. A VTG can contain 4 VT1.5s (T1s), 3 VT2s
(E1s), 2 VT3s or a single VT6. Altogether, the SPE can carry 28 T1s
or carry 21 E1s.
The fractional STS-1 encapsulation can optionally carry a bit mask
that specifies which VTs are carried within the STS-1 payload and
which VTs have been removed. This optional bit mask attribute allows
the ingress circuit emulation node to remove an unequipped VT on the
fly, providing the egress circuit emulation node enough information
for reconstructing the VTs in the right order. The use of bit mask
enables "on the fly" compression, whereby only equipped VTs (carrying
actual data) are sent.
10.2.1.1 Fractional STS-1 CEP header
The fractional STS-1 CEP header uses the STS-1 CEP header
encapsulation as defined in this draft. Optionally, an additional 4
byte header extension word is added. The extended header is
described in Figure 13.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|0|0|0| Equipped Bit Mask (EBM) [0:27] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 63 - Extended Fractional STS-1 Header
The following fields are used within the extended header:
- R, D, N, P, Structured Pointer and Sequence Number: All
fields are used as defined in this draft for STS-1
encapsulation.
- E: Extension bit.
E=0: indicates that extended header is not used.
E=1: indicates that extended header is carried within the
packet.
The E bit in the first word is set to 1 to indicate use
of the Equipped Bit Mask (EBM). The E bit in the second
word indicates whether the extended header (to be defined
in future revision of this draft) is used.
pwe3-sonet Expires December 2003 [Page 28]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
- EBM: Each bit within the bit mask refers to a different VT
within the STS-1 container. A bit set to 1 indicates that
the corresponding VT is equipped, hence carried within the
fractional STS-1 payload.
The format of the EBM is defined in Figure 14.
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VTG7 | VTG6 | VTG5 | VTG4 | VTG3 | VTG2 | VTG1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 - Equipped Bit Mask (EBM) for fractional STS-1
The 28 bits of the EBM are divided into groups of 4 bits, each
corresponding to a different VTG within the STS container. All 4 bits
are used to indicate whether VT1.5 (T1) tributaries are carried
within a VTG. The first 3 bits read from right to left are used to
indicate whether VT2 (E1) tributaries are carried within a VTG. For
example, the EBM of a fully occupied STS-1 with VT1.5 is all ones,
while that of an STS-1 fully occupied with VT2 (E1) tributaries has
the binary value 0111011101110111011101110111.
10.2.1.2 B3 Compensation
Fractional STS-1 encapsulation can be implemented in Line
Terminating Equipment (LTE) or in Path Terminating Equipment (PTE).
PTE implementations terminate the path layer at the ingress PE and
generate a new path layer at the egress PE.
LTE implementations do not terminate the path layer, and therefore
need to keep the content and integrity of the POH bytes across the
PSN. In LTE implementations, special care must be taken to maintain
the B3 bit-wise parity POH byte. The B3 compensation algorithm is
defined below.
Since the BIP-8 value in a given frame reflects the parity check
over the previous frame, the changes made to BIP-8 bits in the
previous frame shall also be considered in the compensation of BIP-8
in the current frame. Therefore the following equation shall be used
for compensation of the individual bits of the BIP-8:
pwe3-sonet Expires December 2003 [Page 29]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1)
Where:
B3[i] = the existing B3[i] value in the incoming signal
B3[i]' = the new (compensated) B3[i] value.
B3*[i] = the B3[i] value of the unequipped VT(VC)s in the
incoming signal
|| = exclusive OR operator.
t = the time of the current frame.
t-1 = the time of the previous frame.
The egress PE MUST reconstruct the unequipped VTs and modify the B3
parity value in the same manner to accommodate for the additional VTs
added. In this way the end-to-end BIP is preserved.
10.2.2 Asynchronous T3/E3 STS-1 (VC-3) Encapsulation
Asynchronous T3/E3 STS-1 (VC-3) encapsulation is applicable for STS-
1 with POH signal label byte C2=4, carrying asynchronous mapping of
T3 or E3 signals.
A T3 is encapsulated asynchronously into an STS-1 SPE using the
format defined in section 3.4.2.1 of [GR253]. The STS-1 SPE is then
encapsulated as defined in this draft.
Optionally, the STS-1 SPE can be compressed by removing the fixed
columns leaving only data columns. STS-1 columns are numbered 1 to
87, starting from the POH column numbered 1. The following columns
have fixed values and are removed:
2, 3, 30, 31, 59, 60
Figure 85 - Fixed columns removed within T3 mapping to STS-1
Bandwidth saving is approximately 7% (6 columns out of 87). The B3
parity byte need not be modified as the parity of the fixed columns
amounts to zero.
A T3 is encapsulated asynchronously into a VC-3 container as
described in section 10.1.2.1 of [G.707]. VC-3 container has only 85
data columns, which is identical to the STS-1 container with the two
fixed stuff columns 30 and 59 removed. Other than that, the mapping
is identical.
An E3 is encapsulated asynchronously into a VC-3 SPE using the
format defined in section 10.1.2.2 of [G.707]. The VC-3 SPE is then
encapsulated as defined in this draft.
pwe3-sonet Expires December 2003 [Page 30]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Optionally, the VC3 SPE can be compressed by removing the fixed
columns leaving only data columns. VC-3 columns are numbered 1 to 85
(and not 87), starting from the POH column numbered 1. The following
columns have fixed values and are removed:
2, 6, 10, 14, 18, 19, 23, 27, 31, 35, 39, 44, 48,
52, 56, 60, 61, 65, 69, 73, 77, 81
Figure 16 - Fixed columns removed within E3 mapping to VC-3
Bandwidth saving is approximately 28% (24 columns out of 85). The B3
parity byte need not be modified as the parity of the fixed columns
amounts to zero.
Implementations of asynchronous T3/E3 STS-1 (VC-3) encapsulation
MUST support payload length of one SPE and MAY support payload
length of 1/3 SPE. The actual payload size are smaller and are
described in appendix B.
10.2.3 Fractional VC-4 Encapsulation
SDH defines a mapping of VC-11, VC-12, VC-2 and VC-3 directly into
VC-4. This mapping does not have an equivalent within the SONET
hierarchy. The VC-4 mapping is common in SDH implementations.
VC-4 <--x3-- TUG-3 <----x1-------- TU-3 <---- VC-3 >---- E3/T3
|
+--x7-- TUG-2 <--x1- TU-2 <-- VC-2 <---- DS-2
|
+----x3---- TU-12 <-- VC-12<---- E1
|
+----x4---- TU-11 <-- VC-11<---- T1
Figure 17 - Mapping of VCs into VC-4
Figure 17 describes the mapping options of VCs into VC-4. A VC-4
contains three TUG-3s. Each TUG-3 is composed of either a single TU-
3, or 7 TUG-2s. A TU-3 contains a single VC-3. A TUG-2 contains
either 4 VC-11s (T1s), 3 VC-12s (E1s) or one VC-2. Therefore a VC-4
may contain 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc.
Fractional VC-4 encapsulation carries only selected set of VCs
within a VC-4 container. This mode is applicable for VC-4 with POH
signal label byte C2=2 (TUG structure) and for C2=3 (Locked TU-n).
The mapping of VCs into a VC-4 container is described in section 7.2
of [G.707]. The CEP packetizer removes all fixed column bytes and
all bytes that belong to the removed VCs. Only VC-4 POH bytes and
bytes that belong to the selected VCs are carried within the
pwe3-sonet Expires December 2003 [Page 31]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
payload. The CEP de-packetizer adds the fixed stuff bytes and
generates unequipped VC data replacing the removed VC bytes.
The fractional VC-4 encapsulation can optionally carry a bit mask
that specifies which VCs are carried within the VC-4 payload and
which VCs have been removed. This optional bit mask attribute allows
the ingress circuit emulation node to remove an unequipped VCs on the
fly, providing the egress circuit emulation node enough information
for reconstructing the VCs in the right order. The use of bit mask
enables "on the fly" compression, whereby only equipped VCs (carrying
actual data) are sent.
VC-3 carrying asynchronous T3/E3 signals within the VC-4 container
can optionally be compressed by removing the fixed column bytes as
described in section 7.2.2, providing additional bandwidth saving.
Implementations of fractional VC-4 encapsulation MUST support
payload length of 1/3 SPE and MAY support payload lengths of 4/9,
5/9, 6/9, 7/9, 8/9 and full SPE. The actual payload size of
fractional VC-4 encapsulation depends on the number of VCs carried
within the payload. The possible actual payload sizes are described
in appendix B.
10.2.3.1 Fractional VC-4 Mapping
[G.707] defines the mapping of TUG-3 to a VC-4 in section 7.2.1. Each
TUG-3 includes 86 columns. TUG-3#1, TUG-3#2 and TUG-3#3 are byte
multiplexed, starting from column 4. Column 1 is the VC-4 POH, while
columns 2 and 3 are fixed, and therefore removed within the
fractional VC-4 encapsulation.
The mapping of TU-3 into TUG-3 is defined in section 7.2.2 of
[G.707]. The TU-3 consists of the VC-3 with a 9-byte VC-3 POH and
the TU-3 pointer. The first column of the 9-row by 86-column TUG-3
is allocated to the TU-3 pointer (bytes H1, H2, H3) and fixed stuff.
The phase of the VC-3 with respect to the TUG-3 is indicated by the
TU-3 pointer.
The mapping of TUG-2 into TUG-3 is defined in section 7.2.3 of
[G707]. The first two columns of the TUG-3 are fixed and therefore
removed in the fractional VC-4 encapsulation. The 7 TUG-2, each 12
columns wide, are byte multiplexed starting from column 3 of the TUG-
3. This is the equivalent of multiplexing 7 VTGs within STS-1
container in SONET terminology, except for the location of the fixed
columns.
The static fractional VC-4 mapping assumes that both the ingress and
egress nodes are preconfigured with the set of equipped VCs carried
within the fractional VC-4 encapsulation. The ingress emulation edge
removes the fixed columns as well as columns of the VCs agreed upon
by the two edges, and updates the B3 VC-4 byte. The egress side adds
the fixed columns and the unequipped VCs and updates B3.
pwe3-sonet Expires December 2003 [Page 32]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
10.2.3.2 Fractional VC-4 CEP Header
The fractional VC-4 CEP header uses the VC-4 CEP header encapsulation
defined Section 3.3 in this draft. Optionally, an additional 12 byte
header extension word is added. The extended header is described in
Figure 18.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 - Extended Fractional VC-4 Header
The following fields are used within the extended header:
- R, D, N, P, Structured Pointer and Sequence Number: All
fields are used as defined in this draft for VC-4
encapsulation.
- E: Extension bit.
E=0: indicates that extended header is not used.
E=1: indicates that extended header is carried within the
packet.
The E bit in the first word is set to 1 to indicate use
of the Equipped Bit Mask (EBM). The E bit in the forth
word indicates whether the extended header (to be defined
in future revision of this draft) is used. The MSB bit of
word two and three is always set to 1 to indicate that
header is extended.
- EBM: The Equipped Bit Mask indicate which tributaries are
carried within the fractional VC-4 payload.
Three EBM fields are used. Each EBM field corresponds to a different
TUG-3 within the VC-4. The EBM includes 7 groups of 4 bits per TUG-2.
A bit set to 1 indicates that the corresponding VC is equipped, hence
carried within the fractional VC-4 payload. Additional 2 bit within
the EBM indicates whether VC-3 carried within the TUG-3 is equipped
and whether it is in AIS mode.
pwe3-sonet Expires December 2003 [Page 33]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
The format of the EBM for fractional VC-4 is defined corresponding to
one of the TUG-3 is defined in Figure 19.
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|T|TUG2#7 |TUG2#6 |TUG2#5 |TUG2#4 |TUG2#3 |TUG2#2 |TUG2#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 - Equipped Bit Mask (EBM) for fractional VC-4
The 30 bits of the EBM are divided into two bits that control the VC-
3 within the TUG-3 and 7 groups of 4 bits, each corresponding to a
different TUG-2 within the TUG-3 container.
For a TUG-3 containing TUG-2, the first two A and T bits MUST be set
to zero. The TUG-2 bits indicate whether the VCs within the TUG-2 are
equipped. All 4 bits are used to indicate whether VC11 (T1)
tributaries are carried within a TUG-2. The first 3 bits read right
to left are used to indicate whether VC12 (E1) tributaries are
carried within a TUG-2. The first bit is used to indicate a VC-2 is
carried within a TUG-2. For example, 28 bits of the EBM of a fully
occupied TUG-3 with VC11 is all ones, while that of a TUG-3 fully
occupied with VC12 (E1) tributaries has the binary value
0111011101110111011101110111.
For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to zero. The
A and T bits are defined as follows:
T : TUG-3 carried bit. If set to 1, the VC-3 payload is carried
within the TUG-3 container. If set to 0, all the TUG-3 columns are
not carried within the fractional VC-4 encapsulation. The TUG-3
columns are removed either because the VC-3 is unequipped or in AIS
mode.
A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 (i.e.
when the TUG-3 columns are carried within the fractional VC-4
encapsulation). The A bit indicate the reason for removal of the
entire TUG-3 columns. If set to 0, the TUG-3 columns were removed
because the VC-3 is unequipped. If set to 1, the TUG-3 columns were
removed because the VC-3 is in AIS mode.
10.2.3.3 B3
Fractional VC-4 encapsulation can be implemented in Line Terminating
Equipment (LTE) or in Path Terminating Equipment (PTE). PTE
implementations terminate the path layer at the ingress PE and
generate a new path layer at the egress PE. LTE implementations do
not terminate the path layer, and therefore need to keep the content
and integrity of the POH bytes across the PSN. In LTE
implementations, special care must be taken to maintain the B3 bit-
wise parity POH byte. The same procedures for B3 compensation as
described in section 7.2.1.2 for fractional STS-1 encapsulation are
used.
pwe3-sonet Expires December 2003 [Page 34]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
11 Signaling of CEP PW
CEP PW signaling for MPLS PSN is based on [PWE3-CONTROL], where PW
setup through LDP is defined. [PWE3-CONTROL] uses the following CEP
specific parameters:
- The PW type is set to SONET/SDH Circuit Emulation over Packet
(CEP).
- The interface parameters field contains (in addition to other
common fields) the CEP Payload bytes, the CEP option and the
CEP/TDM bit rate parameters.
11.1 CEP payload bytes
This parameter MUST contain the expected CEP packet length without
network headers and control word. In case of Fractional SPE mode, it
contains the packet length before removal of the unequipped VT
containers, and effectively represents the full SPE mode equivalent
length before the VT level processing.
Note that in fractional SPE, the actual (i.e. on the wire) packet
length may be less than advertised, and in dynamic fractional SPE,
even change while the connection is active.
A PE that receives a label-mapping message with request for a packet
length value that is not locally supported should return the
appropriate error code as in [PWE3-CONTROL], and the PWC is not
established.
11.2 CEP/TDM bit rate
This parameter MUST contain the data rate in 64Kbps units of the CEP
PW payload. If the CEP connection supports both EBM and dynamic
unequipped lower order containers suppression this parameter
represents the peak connection rate (i.e. as if the SPE is fully
equipped).
Attempts to establish a PWC between two peers with different bit-
rates MUST be rejected with the appropriate status code as in [PWE3-
CONTROL].
pwe3-sonet Expires December 2003 [Page 35]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
11.3 CEP options
The format of the CEP option parameter is shown in Figure 20.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM|PID| RESERVED [0:5] | CEP Type | Async |
| | | | | | | [0:2] |DS3|E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 20 - CEP Options
AIS When set, indicate that the system sending the label-mapping
message is able to accept DBA packets with AIS indication.
UNE - When set, indicate that the system sending the label-mapping
message is able to accept DBA packets with UNEQ indication.
RTP When set, indicate that RTP header is required.
EBM - When set, indicate that EBM header is required.
PID When set, indicate that MPLS PID is required.
CEP Type indicate the CEP connection type:
0x0 SPE mode (i.e. STS-1 or STS-Mc)
0x1 VT mode (VT1.5/VT2/VT3/VT6 inferred from CEP bit rate)
0x2 Fractional SPE (STS-1/VC-3/VC-4)
Async Type indicate the Async E3/DS3 bandwidth reduction
capabilities. Relevant only when CEP type is set to fractional SPE,
and fractional SPE is expected to carry Asynchronous DS-3/E3
payload:
DS-3 When set, indicate that the system sending the label-mapping
message is able to accept Fractional SPE packets with DS3 bandwidth
reduction.
E3 When set, indicate that the system sending the label-mapping
message is able to accept Fractional SPE packets with E3 bandwidth
reduction.
A system that does not support the DBA option or one of the DBA sub
option, can simply ignore label-mapping messages with either AIS or
UNE bits set, and no further protocol action is required. A system
that is configured to use one of the DBA options but receives a
label-mapping message indicating that its peer cannot process DBA
packets MUST not use the DBA option, and SHOULD report the mismatch
to the operator.
pwe3-sonet Expires December 2003 [Page 36]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
A system that does not support the Async bandwidth reduction mode
can simply ignore label-mapping messages with either DS-3 or E-3
bits set, and no further protocol action is required. A system that
is configured to use one of the Async options but receives a label-
mapping message indicating that its peer cannot process Async
bandwidth reduction T3/E3 payloads MUST not use the Async option,
and SHOULD report the mismatch to the operator.
The setting of the CEP type, RTP, EBM and PID MUST be consistent
between peers. If a peer receives a label-mapping message with
inconsistent setting compared with the local configuration, it
should send a label-withdraw message with status code of CEP mis-
configuration, report to the operator and wait for a new
(consistent) label mapping. A system MUST send a new label-mapping
message once it is re-configured.
12 Open Issues
No open issues.
13 Security Considerations
This document does not address or modify security issues within the
relevant PSNs.
14 Intellectual Property Disclaimer
This document is being submitted for use in IETF standards
discussions. Tellabs, Inc. and Lycium Networks, Inc. have filed one
or more patent applications relating to the CEP technology described
in this document. In the event that Tellabs, Inc is granted a patent
or patents essential to the implementation of this document,
Tellabs, Inc. agrees to grant a free unlimited license to all
parties implementing the document, subject to reciprocity of the
licensed party. In the event that Lycium Network, Inc is granted a
patent or patents essential to the implementation of this document,
Lycium Networks, Inc. agrees to grant a free unlimited license to
all parties implementing the document, subject to reciprocity of the
licensed party.
pwe3-sonet Expires December 2003 [Page 37]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
15 References
Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC2026, October 1996.
[PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation
Edge-to-Edge (PWE3), Work in Progress, June 2003, draft-ietf-pwe3-
requirements-06.txt
[PWE3-TDM-REQ] Max Riegel, Requirements for Edge-to-Edge Emulation
of TDM Circuits over Packet Switching Networks (PSN), Work in
Progress, June 2003, draft-ietf-pwe3-tdm-requirements-01.txt.
[PWE3-ARCH] Stewart Bryant and Prayson Pate, PWE3 Architecture, Work
in progress, October 2003, draft-ietf-pwe3-arch-06.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SONET] American National Standards Institute, "Synchronous Optical
Network (SONET) - Basic Description including Multiplex Structure,
Rates and Formats," ANSI T1.105-1995.
[GR253] Telcordia Technologies, Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria, GR-253-CORE, Issue 3,
September 2000.
[G707] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996.
[RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real-
Time Applications, RFC 1889, IETF, 1996
[PWE3-CONTROL] Martini et al, Pseudo-wire Setup and Maintenance
using LDP, draft-ietf-pwe3-control-protocol-03.txt, work in
progress, July 2003.
Informative References
[CEP-MIB] Danenberg et al, "SONET/SDH Circuit Emulation Service Over
PSN (CEP) Management Information Base Using SMIv2",draft-ietf-pwe3-
cep-mib-01.txt, work in progress, October 2002.
[RFC2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links, RFC 2508, IETF, 1999
[RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC
3095, IETF, 2001
pwe3-sonet Expires December 2003 [Page 38]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
[AAL1] ITU-T, Recommendation I.363.1, B-ISDN Adaptation Layer
Specification: Type AAL1, Appendix III, August 1996.
[L2TPv3] Layer Two Tunneling Protocol (Version 3)'L2TPv3', J Lau,
et. al. <draft-ietf-l2tpext-l2tp-base-10.txt>, work in progress,
August 2003.
pwe3-sonet Expires December 2003 [Page 39]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
16 Authors Addresses
Andrew G. Malis
Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Email: Andy.Malis@tellabs.com
Ken Hsu
Tellabs, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Email: Ken.Hsu@tellabs.com
Jeremy Brayley
Laurel Networks, Inc.
2706 Nicholson Rd.
Sewickley, PA 15143
Email: jbrayley@laurelnetworks.com
Steve Vogelsang
Laurel Networks, Inc.
2706 Nicholson Rd.
Sewickley, PA 15143
Email: sjv@laurelnetworks.com
John Shirron
Laurel Networks, Inc.
2607 Nicholson Rd.
Sewickley, PA 15143
Email: jshirron@laurelnetworks.com
Luca Martini
Level 3 Communications, LLC.
1025 Eldorado Blvd.
Broomfield, CO 80021
Email: luca@level3.net
Tom Johnson (Editor)
Litchfield Communications, Inc.
Ed Hallman
Litchfield Communications, Inc.
Marlene Drost
Litchfield Communications, Inc.
pwe3-sonet Expires December 2003 [Page 40]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Jim Boyle
Protocol Driven Networks, Inc.
1381 Kildaire Farm #288
Cary, NC 27511
Email: jboyle@pdnets.com
David Zelig
Corrigent Systems
126, Yigal Alon st.
Tel Aviv, ISRAEL
Email: davidz@corrigent.com
Ron Cohen
Lycium Networks
2480 Sand Hill Road,
Menlo-Park, CA, 94025
Email: ronc@lyciumnetworks.com
Prayson Pate
Overture Networks
P. O. Box 14864
RTP, NC, USA 27709
Email: prayson.pate@overturenetworks.com
Craig White
Level3 Communications, LLC.
1025 Eldorado Blvd,
Broomfield CO 80021
Email: Craig.White@Level3.com
pwe3-sonet Expires December 2003 [Page 41]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Appendix A. SONET/SDH Rates and Formats
For simplicity, the discussion in this section uses SONET
terminology, but it applies equally to SDH as well. SDH-equivalent
terminology is shown in the tables.
The basic SONET modular signal is the synchronous transport signal-
level 1 (STS-1). A number of STS-1s may be multiplexed into higher-
level signals denoted as STS-N, with N synchronous payload envelopes
(SPEs). The optical counterpart of the STS-N is the Optical Carrier-
level N, or OC-N. Table 2 lists standard SONET line rates discussed
in this document.
OC Level OC-1 OC-3 OC-12 OC-48 OC-192
SDH Term - STM-1 STM-4 STM-16 STM-64
Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280
Table 2 - Standard SONET Line Rates
Each SONET frame is 125 µs and consists of nine rows. An STS-N frame
has nine rows and N*90 columns. Of the N*90 columns, the first N*3
columns are transport overhead and the other N*87 columns are SPEs.
A number of STS-1s may also be linked together to form a super-rate
signal with only one SPE. The optical super-rate signal is denoted
as OC-Nc, which has a higher payload capacity than OC-N.
The first 9-byte column of each SPE is the path overhead (POH) and
the remaining columns form the payload capacity with fixed stuff
(STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1
columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed
stuff, STS-12c has three columns of fixed stuff, and so on.
The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The
payload capacity of an STS-1 is 86 columns (774 bytes) per frame.
The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame.
Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340
bytes per frame. As another example, the payload capacity of an STS-
192c is 149,760 bytes, which is 64 times the capacity of an STS-3c.
There are 8,000 SONET frames per second. Therefore, the SPE size,
(POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112
Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame
or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760
bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2
lists the SPE and payload rates supported.
pwe3-sonet Expires December 2003 [Page 42]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c
SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c
Payload Size(Bytes) 774 2,340 9,360 37,440 149,760
Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640
SPE Size(Bytes) 783 2,349 9,396 37,584 150,336
SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504
Table 3 - Payload Size and Rate
To support circuit emulation, the entire SPE of a SONET STS or SDH
VC level is encapsulated into packets, using the encapsulation
defined in section 4., for carriage across packet-switched networks.
VTs are organized in SONET super-frames, where a SONET super-frame
is a sequence of four SONET SPEs. The SPE path overhead byte H4
indicates the SPE number within the super-frame. The VT data can
float relative to the SPE position. The overhead bytes V1, V2 and
V3 are used as pointer and stuffing byte similar to the use of the
H1, H2 and H3 TOH bytes.
Table 3 below indicates the number of bytes occupied by a VT within
a super-frame.
Mapping VT size Reference
-------------------------------------------------------------
VT1.5/VC-11 104 bytes [GR253] Section 3.4.1.1
VT2/VC-12 140 bytes [G.707] Section 10.1.4.1
VT3 212 bytes [GR253] Section 3.4.1.3
VT6/VC-2 428 bytes [GR253] Section 3.4.1.4
Table 4 - Number of Bytes in a VT Super-frame
To support circuit emulation, the entire SONET SPE or VT or SDH VC
level is encapsulated into packets, using the encapsulation defined
in section 3, for carriage across packet-switched networks.
pwe3-sonet Expires December 2003 [Page 43]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Appendix B. Payload sizes
CEP packets are normally fixed in length for all packets of a
particular emulated SONET/SDH stream. The exceptions are DBA CEP
packets and on the fly compression within the fractional STS-1/VC-
3/VC-4 mode. When the fractional encapsulation does not carry the
equipped flag indications, the EBM to be transmitted MUST be
statically provisioned at both ends. The length of each CEP packet
does not need to be carried in the CEP header because it can be
uniquely determined for each CEP packet as a function of the
provisioned payload size, the type of VTs carried within the STS-1
signal, the DBA indication and the equipped flags (either
dynamically or statically provisioned).
The following payload lengths can be statically provisioned for
fractional STS-1 encapsulations:
1. Full SPE length (783 bytes)
2. Third of SPE length (261 bytes)
The actual payload sizes would be smaller, depending on the number
of virtual tributaries carried within the fractional SPE. Table 5
provides the actual payload length as a function of N, the number of
tributaries carried within the fractional STS-1. In particular, when
all VTs are equipped, the fractional STS-1 full SPE payload size is
765 bytes.
VT Type Full SPE SPE/3
----------------------------------------------
VT1.5 (T1) 27*N+9 9*N+3 N=0..28
VT2 (E1) 36*N+9 12*N+3 N=0..21
Table 5 - Fractional STS-1 Actual Payload Size
The following payload lengths can be statically provisioned for
fractional VC-4 encapsulation:
1. Full SPE length (2349 bytes)
2. 8/9 SPE length (2088 bytes)
3. 7/9 SPE length (1827 bytes)
4. 6/9 SPE length (1566 bytes)
5. 5/9 SPE length (1305 bytes)
6. 4/9 SPE length (1044 bytes)
7. 1/3 SPE length (783 bytes)
Table 6 Configurable fractional VC-4 Payload Length
The actual payload sizes would be smaller, depending on the number
of virtual tributaries carried within the fractional SPE. Each
equipped VC contributes the following number of bytes per SPE:
pwe3-sonet Expires December 2003 [Page 44]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Each VC-11 contributes 27 bytes
Each VC-12 contributes 36 bytes
Each VC-2 contributes 108 bytes
Each VC-3(DS-3) contributes 738 bytes (including pointers)
Each VC-3(E-3) contributes 576 bytes (including pointers)
Each VC-3(not compressed) contributes 774 bytes (including
pointers)
Table 7 - Fractional VC-4 Actual Payload Size
For example, the payload size of a fractional VC-4 configured to
third SPE encapsulation that carries a single T3 VC-3 and 6 VC-12s
would be: 9 (VC-4 POH) + 6 * 36 + 738 / 3 = 321 bytes payload per
each packet.
The following payload lengths can be statically provisioned for
asynchronous T3/E3 STS-1/VC-3 encapsulations:
1. Full SPE length (783 bytes)
2. Third of SPE length (261 bytes)
Table 8 Configurable fractional STS-1/VC-3 Payload Length
The actual payload sizes would be smaller as described below.
Signal Full SPE SPE/3
----------------------------------------------
T3 729 243
E3 567 189
Table 9 - Asynchronous T3/E3 STS-1/VC-3 Actual Payload Size
pwe3-sonet Expires December 2003 [Page 45]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Appendix C: Example Network Diagram
Figure 22 below shows an example of SONET interconnect. Site A and
Site B are connected back to a Hub Site, Site C by means of a SONET
infrastructure. The OC3 from Site A and the OC12 from Site B are
partially equipped. Each of them is transported through a SONET
network back to a hubbing site (C). Equipped SPEs (or VTs) are then
groomed onto the OC-12 towards site C.
SONET Network
____ ___ ____
_/ \___/ \ _/ \__
+------+ Physical / \__/ \
|Site A| OC-12 / +---+ OC-12 \ Hub Site
| |=================|\S/|-------------+-----+ \ +------+
| | \ |/ \|=============|\ /| \ | |
+------+ /\ +---+-------------| \ / | / OC12 | |
/ | S |=========|Site C|
+------+ Physical/ +---+-------------| / \ | \ | |
|Site B| OC-12 \ |\S/|=============|/ \| \ | |
| |=================|/ \|-------------+-----+ / +------+
| | \ +---+ OC12 __ /
+------+ \ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 10 - SONET Interconnect Example Diagram
pwe3-sonet Expires December 2003 [Page 46]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Figure 23 below shows the same pair of OC12s being emulated over a
PSN. This configuration frees up bandwidth in the grooming network,
since only equipped SPEs (or VTs) are sent through the PSN.
Additional bandwidth savings can be realized by taking advantage of
the various payload compression options described in section 10.
SONET/TDM/Packet Network
____ ___ ____
_/ \___/ \ _/ \__
+------+ Physical /+-+ \__/ \_
|Site A| OC12 / | | +---+ \ Hub Site
| |=============|P|=| R | +---+ +-+ +-----+ \ +------+
| | \ |E| | |===| | | |=|\ /| \ | |
+------+ /\+-+ +---+ | | | | | \ / | / OC12| |
/ | R |=|P| | S |========|Site C|
+------+ Physical/ +-+ +---+ | | |E| | / \ | \ | |
|Site B| OC12 \ |P| | R |===| | | |=|/ \| \ | |
| |=============|E|=| | +---+ +-+ +-----+ / +------+
| | \ | | +---+ __ /
+------+ \ +-+ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 11 - SONET Interconnect Emulation Example Diagram
Figure 24 below shows an example of T1 grooming into OC-12 in access
networks. The VT encapsulation is used to transport the T1s from the
Hub site to customer sites, maintaining SONET/SDH OA&M.
SONET/TDM/Packet Network
____ ___ ____
_/ \___/ \ _/ \__
+------+ Physical /+-+ \__/ \_
|Site A| T1 / | | +---+ \ Hub Site
| |=============|P|=| R | +---+ +-+ +-----+ \ +------+
| | \ |E| | |===| | | |=|\ /| \ | |
+------+ /\+-+ +---+ | | | | | \ / | / OC12| |
/ | R |=|P| | S |========|Site C|
+------+ Physical/ +-+ +---+ | | |E| | / \ | \ | |
|Site B| T1 \ |P| | R |===| | | |=|/ \| \ | |
| |=============|E|=| | +---+ +-+ +-----+ / +------+
| | \ | | +---+ __ /
+------+ \ +-+ __/ \ /
\ ___ ___ / \_/
\_/ \____/ \___/
Figure 12 - SONET Interconnect Emulation Example Diagram
pwe3-sonet Expires December 2003 [Page 47]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
pwe3-sonet Expires December 2003 [Page 48]
Internet Draft draft-ietf-pwe3-sonet-03 October 2003
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
pwe3-sonet Expires December 2003 [Page 49]
