pseudowire - intranet deibhome.deib.polimi.it/.../2014-2015/12_pseudowire.pdfpseudowire pag. 15...

Paolo Giacomazzi1

Course of Multimedia Internet (Sub-course”Reti Internet Multimediali”), AA 2010-2011 Prof. Paolo GiacomazziPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Via Ponzio, 34/5, 20133 MILANO, ITALY

12. pseudowire Pag. 1

Pseudowire

Quality of Service in IP networks Paolo Giacomazzi2


12. Pseudowire Pag. 2

PseudowireA pseudowire is an emulation of a native service over a packet switched network (PSN)The native service may be low-rate TDM, SDH/SONET, ATM, Frame Relay, or Ethernet while the PSN may be Ethernet, MPLS, or IP (either IPv4 or IPv6)A pseudowire emulates the operation of a "transparent wire" carrying the native serviceThe first pseudowirespecifications were the “Martini Draft” for ATM pseudowires in the backbone or core network, and the TDMoIP for transport of E1/T1 over IP in the access

Source: RAD data communicationshttp://www.pseudowire.com




PseudowireTDM pseudowire carries a real-time bit stream over a PSNConventional TDM networks have numerous special features, in particular those required in order to carry voice-grade telephony channels:

signaling systems operations and Management (OAM)

These features must be accounted for by the TDM pseudowire systemOne critical issue in implementing TDM pseudowires is clock recoveryIn native TDM networks the physical layer carries timing information along with the TDM data, but when emulating TDM over PSNs this physical layer clock is absentThe PSN necessarily inserts delay jitter and the exact timing of the original signal must be recovered

Source: RAD data communicationshttp://www.pseudowire.com




PseudowireSeveral standards of pseudowire exist, among which:

ITU-T Y.1453IETF PWE3 (Pseudowire emulation edge to edge)IETF SAToP (Structure-Agnostic TDM over Packet)IETF CESoPSN (Circuit Emulation Service over PSN )Metro Ethernet Forum

– MEF 3.0: “Circuit Emulation Service Definitions, Framework and Requirements in Metro Ethernet Networks” and

– MEF 8.0: “Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks”

IP-MPLS forum




PseudowireThe bit rates traditionally used in various regions of the world are detailed in the normative reference ITU-T G.702For example, in North America, the T1 bit stream of 1.544 Mbps and the T3 bit stream of 44.736 Mbps are mandated, while in Europe, the E1 bit stream of 2.048 Mbps and the E3 bit stream of 34.368 Mbps are utilizedAlthough TDM can be used to carry unstructured bit streams, there is a standardized method of carrying bit streams in larger units called frames, each frame contains the same number of bitsRelated to the sampling frequency of voice traffic the bitrate is always a multiple of 8000, hence the T1 frame consists of 193 bits and the E1 frame of 256 bitsThe number of bits in a frame is called the frame sizeThe framing is imposed by introducing a periodic pattern into the bit stream to identify the boundaries of the frames (e.g., 1 framing bit per T1 frame, a sequence of 8 framing bits per E1 frame)Unframed TDM has all bits available for payloadFramed TDM is often used to multiplex multiple channels (e.g., voice channels each consisting of 8000 8-bit-samples per second) in a sequence of "timeslots" recurring in the same position in each frameThis multiplexing is called "channelized TDM" and introduces additional structure




Pseudowire: TDM Structure and Transport ModesUnstructured TDM:

TDM that consists of a raw bit-stream of rate defined in G.702, with all bits available for payload

Structured TDM:TDM with one or more levels of structure delineation, including frames, channelization, and multiframes

Structure-Agnostic Transport:Transport of unstructured TDM, or of structured TDM when the structure is deemed inconsequential from the transport point of viewIn structure-agnostic transport, any structural overhead that may be present is transparently transported along with the payload data, and the encapsulation provides no mechanisms for its location or utilization

Structure-Aware Transport:Transport of structured TDM taking at least some level of the structure into accountIn structure-aware transport, there is no guarantee that all bits of the TDM bit-stream will be transported over the PSN network (specifically, the synchronization bits and related overhead may be stripped at ingress and usually will be regenerated at egress)




Y.1453: IP packet formats for pseudowireTDM-IP interworking is treated in the ITU-T Y.1453 recommendationThe recommendation addresses required functions for network interworking between TDM networks up to DS3 or E3 rates and IP networks, in order to transport TDM traffic over IP networksUser plane interworking mechanisms are addressed, along with connection multiplexing and proceduresThese interworking mechanisms must ensure that TDM timing, signalling, voice quality, and alarm integrity be maintained




Y.1453: TDM-IP interworkingTDM services are normally transported over networks operating in circuit-switched modeA TDM client requires that its server layer constrains accuracy, ordering, and temporal impairments within defined boundsFor a connectionless server layer, the severity of these impairments may increase significantly with server layer loadingAs the server layer loading may not be known in advance, and may vary over time, the layering of a TDM client over an IP server presents a significant challenge for equipment manufacturers and service providers to conform to TDM performancePacket loss, delay and delay variation will degrade the TDM service quality




Y.1453: TDM-IP interworkingThe figure provides a general network architecture for TDM-IP network interworking where TDM networks are interconnected through an IP network Note that the path through the IP network may (or may not) change over time as a result of IP routing protocolsFor the TDM-to-IP direction, the continuous TDM stream is segmented and encapsulated into UDP/IP packets by the interworking function (IWF)For the IP-to-TDM direction, the TDM segments are extracted from the UDP/IP packets and the continuous TDM stream is reassembled




Y.1453: TDM-IP interworkingAn alternative representation of the TDM-IP interworking is shown in the figureLegend:

TDM CP: TDM connection pointIP AP: IP access pointIP TFP: IP termination flow point




Y.1453: TDM-IP interworkingThe following figure shows the network reference model and the protocol layering model for the interworking of TDM and IP




Y.1453: TDM-IP interworking: user plane requirementsFor transfer of TDM streams over IP networks, the following capabilities are required:

The ability to transport multiple TDM streams between two IWFsSupport for bidirectional flows with symmetric bandwidth and binding to the duplex TDMThe ability to transport the following TDM types: DS1 (T1, 1.544 Mbit/s), E1 (2.048 Mbit/s), DS2 (T2, 6.312 Mbit/s), V.36 (56/64 kbit/s), N × 64 k, DS3 (T3, 44.736 ), E3 (34.368 Mbit/s)




Y.1453: TDM-IP interworking: fault management requirementsThe interworking function supports the transfer of defect information between IP and TDM networksLoss of signal or loss of synchronization are signalled from ingress to egress IWFsIP anomalies, such as packet misordering and loss, are detected by the egress IWFThe interworking function transfers TDM defect indications through the IP network by setting appropriate flags in the common interworking indicatorsIf applicable, appropriate alarms are sent to the management layerThe egress IWF detects IP anomalies by monitoring the timely arrival of packets and by the sequence number in the common interworking indicatorsThe egress IWF ensures synchronization integrity of its local TDM interface and maintains a statistical record of anomalies




Y.1453: Traffic managementIf the IP network is Diffserv enabled according to RFC 2474, then expedited forwarding per hop behaviour (EF PHB) per RFC 3246 with appropriate traffic conditioning shall be used in order to provide a low latency and minimal jitter serviceIt is suggested that the IP network be over provisioned (as it has been discussed previously)If the IP network is Intserv enabled according to RFC 2210 [28], then guaranteed service (GS) per RFC 2212 [29] shall be used




Y.1453: Connection admission controlWhen bandwidth guarantees can be provided, then the IWF should provide connection admission controlThe admission decision shall be based on the total bandwidth allocation of the IP network, the bandwidth presently being consumed by interworking flows and other clients of the IP network, and the bandwidth requestedWhen sufficient bandwidth is available, the request may be grantedWhen bandwidth is insufficient, the TDM connection request must be denied




Y.1453: Functional groupsIP is the standard IPv4 or IPv6 protocolSince it may be required to transport multiple emulated TDM streams between two IP addresses, a method of labelling TDM-IP flows is requiredOnly manual provisioning of this label is consideredThe label may be placed in the UDP source port field, or the UDP destination port field When the source port field is used, the destination port field may contain an identifier indicating that the packet contains TDM data




Y.1453: Functional groupsThe functions in the Common interworking indicators are related to the interworking flow and are independent of any specific service or encapsulationIn general the Common interworking indicators is comprised of

a control fielda fragmentation fielda length fielda sequence number field




Y.1453: Functional groupsThe reserved field shall be set to zero.The L, R and M fields provide a means of transfer of TDM defect indications between IWFsL, Local TDM failure

The L bit being set (i.e., L = 1) indicates that the ingress IWF has detected or has been informed of a TDM defect impacting the TDM dataWhen the L bit is set the contents of the packet may not be meaningful, and the payload may be suppressed




Y.1453: Functional groupsR Remote Receive failure

The R bit being set (i.e., R = 1) indicates that the source of the packet is not receiving packets from the IP networkThus the setting of the R bit indicates failure of the opposite directionThis indication can be used to signal IP network congestion or other network related faultsThe R bit shall be set after a preconfigured number of consecutive packets are not received, and shall be cleared once packets are once again received




Y.1453: Functional groupsM Defect Modifier

Use of the M field is optional, and when used it supplements the meaning of the L bitWhen L is cleared (indicating valid TDM data), the M field is used as follows:0 0 Indicates no local defect modification1 0 Reports receipt of RDI (Remote Defect Indication) at the TDM input to the ingress IWFWhen L bit is set (indicating invalid TDM data), the M field is used as follows:0 0 Indicates a TDM defect that should trigger AIS (Alarm Indication Signal) generation at the far end0 1 Indicates idle TDM data, which should not cause any alarm to be raised. If the payload has been suppressed, then appropriate idle code should be generated at egress.




Y.1453: Functional groupsFragmentation field: this field is used for fragmenting multi-frame structures into multiple packetsThe field is used as follows:

0 0 Indicates that the entire (unfragmented) multi-frame structure is carried in a single packet.0 1 Indicates the packet carrying the first fragment1 0 Indicates the packet carrying the last fragment1 1 Indicates a packet carrying an intermediate fragment




Y.1453: Functional groupsLength field

When an IP packet is transported over Ethernet, a minimum packet size of 64 octets is requiredThis may require padding to be applied to the interworking packet payload in order to reach this minimum packet sizeThe padding size can be determined from the length field so that the padding can be extracted at the egress

The Length field indicates the size of the IP packet payload in octets, and its value is the sum of:

size of the Common interworking indicators (4 octets);size of the optional timing informationsize of the payload




Y.1453: Functional groupsThe Sequence number field is a two-octet field that is used to detect lost packets and packet misorderingThe sequence number space is a 16-bit, unsigned circular spaceThe sequence number should be set to a random value for the first IP packet transmittedFor each subsequent IP packet, the sequence number shall be incremented by 1, modulo 216Misordered packets should be reordered, if possibleThe following procedures apply at the egress IWF (IP-to-TDM direction):

The egress IWF maintains an expected sequence numberThe first packet received from the IP network is always considered to be the expected packet, and the expected sequence number is equated to its sequence numberIf the sequence number equals or is greater (in the cyclic sense) than the expected number, then the expected sequence number is set to the received number incremented by 1 modulo 216, otherwise the expected number is unchanged




Y.1453: Functional groupsOptional timing information may be carried using the RTP header If used, the RTP header shall appear in each interworking packet immediately after the UDP/IP header and before the common interworking indicators field




Y.1453: Encapsulation formatThe figure shows the structure of an IP datagram carrying a segment of the TDM flowThe figure refers to the case in which RTP is not used




Y.1453: Encapsulation formatThe figure shows the structure of an IP datagram carrying a segment of the TDM flowThe figure refers to the case in which RTP is used




Y.1453: Number of PDUs per IP packetThe number of PDUs per IP packet is preconfigured and typically chosen taking into account latency and bandwidth constraintsUsing a single PDU reduces latency to a minimum, but incurs the highest overheadSuggested values are between 1 and 8 PDUs per packet for E1 and DS1 circuits, and between 5 and 15 PDUs per packet for E3 and DS3 circuitsUsing eight or more PDUs per packet invalidates the use of the AAL 1 sequence number mechanism, and hence complicates interworking with ATM-based CES systems




Y.1453: On packet lossMalformed packets and out of order packets may be considered as lostRetransmission is not a viable option for TDM-IP interworking, and so appropriate action shall be taken to compensate for packet lossWhen loss of packets is detected, the IWF shall insert the required amount of filler data towards the End System in order to retain TDM timingWhen CAS is employed, care should be taken by structure-aware mechanisms to maintain signalling stateStructure-agnostic transport cannot identify structure overhead, and so transports it transparently in the TDM segments; hence, filler data will in general introduce an incorrect FAS




Timing recoveryPackets in the PSN reach their destination with delay that has a random component, known as packet delay variation (PDV)When emulating TDM transport on such a network, this randomness may be overcome by placing the TDM packets into a jitter buffer from which data can be read out at a constant rate for delivery to TDM end-user equipmentThe problem is that the TDM source time reference is no longer available, and the precise rate at which the data are to be "clocked out" of the jitter buffer is unknown




Timing recoveryIn certain cases timing may be derived from the TDM equipment atboth ends of the PWSince each of these clocks is highly accurate, they necessarily agree to high orderThe problem arises when at most one side of the TDM pseudowiretunnel has a highly accurate time standardFor ATM networks, which define a physical layer that carries timing, the synchronous residual time stamp (SRTS) method may be usedIP/MPLS networks, however, do not define the physical layer and thus cannot specify the accuracy of its clockHence, in many cases the only alternative is to attempt to recover the clock based on alternative methods




Timing recoveryAbsolute Mode

This is the normal method used for Real Time Protocol (RTP)The sending end generates a time stamp that corresponds to the sampling time of the first word in the packet payloadThe receiving end uses this information to sequence the messagescorrectly but without knowledge of the sending end’s clock frequency

Differential ModeIn the differential mode, both sending and receiving ends have access to the same high-quality reference clockThe sending end generates time stamps relative to the reference clockThe receiving end uses the time stamps to generate a service clock that matches the frequency relationship of the sending end’s service clock to the reference clockThis method produces the highest quality clock and is affected least by network quality of service issues




Timing recoveryAdaptive Mode

The adaptive clock recovery mode relies on packet inter-arrival time to generate the service clock frequencyThis method does not require time stamps or a reference clock to be present at the receiving endHowever, it is affected by packet inter-arrival jitter more that the other methodsHowever, it is an interesting method adopted in practice for those services which need to comply with jitter requirements but not with wander requirements




SynchronizationThe main goal of the CES IWF is to preserve the service clock of the TDM service through the MENThe operation and definition of the interworking functions are specific to the CES interface type The IWF can use a variety of timing inputs to use as a reference for service clock recoveryThe five available timing inputs used by the CES IWF are

Line timing (from the CE) – This mode is used to recover timing from a CE. In order for this timing mode to PRS traceable, the CE must be provisioned to recover and transmit PRS traceable timing




SynchronizationLine timing (from the MEN) – This mode is used to recover timing from the MEN. In order for this timing mode to be PRS traceable, theadjacent Ethernet NE (in the MEN) must be provisioned to recover and transmit PRS traceable timing. External Timing – This mode is used to recover PRS traceable timing from a co-located building integrated timing supply. Timing is typically sent to the TSP/IWF as an all ones DS1 or E1 with framing. Free-Run – This mode is considered a standalone mode. It should only be used when a suitable line or external timing reference is not available. The frequency and stability of this timing mode is determined by the TSP/IWF’s internal oscillator. Holdover – This mode is usually considered a backup or protection timing mode. Holdover mode may be initiated when the external or line timing references have been lost due to a failure. This failure is indicated to the CES IWF via a loss of frame (LOF), loss of signal (LOS) or SSM indication. Unlike free-run, this timing mode relies on the TSP/IWF’s internal oscillator that has been trained by an external timingreference (e.g., PRS traceable timing source).




Errored Seconds Requirement for PDH CircuitsAn ES is a one-second interval with one or more bit errorsEach 1.544 Mbits/s (including Nx64kbits/s) and 44.736 Mbits/s channel requires that, over 30 or more consecutive days, fewer than 0.25% and 0.125%, respectively, of the seconds are errored secondsThe conversion of ES for PDH circuits to bit error ratio (BER) and frame error ratio (FER) for Ethernet CES virtual circuits is dependant on factors such as the number of TDM frames packed into the CES Ethernet frame (packing density) and the size of the CES header attached to each Ethernet CES frameConversion of the Errored Seconds requirements to an Ethernet Frame Error Ratio is possible based on knowledge of the number of TDM frames packed into each Ethernet frame containing CES

FER = %ES /(100 * CES frame rate)Where: CES frame rate = TDM data rate / (N * bits per TDM frame)N = number of TDM frames per CES frameBits per TDM Frame = 193 for 1.544 Mbits/s; 4760 for 44.736 Mbits/s




Errored Seconds Requirement for PDH CircuitsValues of FER for specific packing densities (8 T1 or E1 frames and 2 T3 or E3 frames) are given in the table

1.544 Mbits/s(T1)

44.736 Mbits/s(T3)

2.048 Mbit/s (E1) 34.368 Mbit/s(E3)

%ES 0.25 0.125 0.7 1.3125

FER 2.5x10-6 2.7x10-7 7.0x10-6 3.3x10-6

pseudowire - intranet deibhome.deib.polimi.it/.../2014-2015/12_pseudowire.pdfpseudowire pag. 15...

Documents