930 likes | 1.49k Views
EoS. Yaakov (J) Stein Chief Scientist RAD Data Communications. Course Outline. 1) Introduction 2) Background - Ethernet 3) Background – HDLC 4) Background - PPP 5) Background - SONET/SDH 6) VCAT 7) LCAS 8) POS (PPP over SONET/SDH – RFC 1619/2615)
E N D
EoS Yaakov (J) Stein Chief Scientist RAD Data Communications
Course Outline 1) Introduction 2) Background - Ethernet 3) Background – HDLC 4) Background - PPP 5) Background - SONET/SDH 6) VCAT 7) LCAS 8) POS (PPP over SONET/SDH – RFC 1619/2615) 9) LAPS 10) GFP 11) Alternatives
Motivation Assume that you are a traditional operator • You have an extensive SONET/SDH network • This network has cost you Millions-Billions to build • This network is highly reliable • Your staff is well trained to maintain it • You may have not yet reached Return On Investment • It supports the service that brings the most revenue – voice • It supports the service with the highest margin – leased lines But suddenly customers are asking for something new • “Ethernet handoff” And new competitors are willing to supply it!
Option 1: install new infrastructure You may choose to build a new IP/MPLS based network (BT 21CN approach) Yes – this means significant investment, but this is definitely the future! But SONET/SDH has comparative advantages: • Reliable optical transport • Well known technology and protocols • Ubiquitous with present operators • Many supported data rates (from 1 Mbps to many Gbps) • Low overhead • Strong OAM (MPLS isn’t there yet …) So if you replace the existing network • How will you handle the service that brings your main income – voice ? • You may lose your existing leased line customers • You will need to solve the timing distribution problem And if you keep your existing network • You need to maintain two completely different networks ! This sounds problematic !
I W F A D M I W F A D M Ethernet Switch Ethernet Switch SONET RING Option 2: leased lines You can try to convince these customers to use leased lines The customer converts traffic into T1/E1 (e.g. by using frame relay) • You can supply this service now • The major expense is for the customer (who needs FRAD, CSU/DSU, etc.) • Leased lines are profitable But this only worked before the new competitors appeared You will probably lose these customers !
A T M A D M A T M A D M Ethernet Switch Ethernet Switch SONET RING Option 3: ATM You can offer ATM service The customer converts traffic into ATM (AAL5) • You can supply this service now • ATM is a well-known technology • ATM is a reliable and high-quality service • ATM maps efficiently onto SONET/SDH • You may even be able to perform the conversion at your POP (but Ethernet is notoriously hard to transport over distances) But ATM has its disadvantages • ATM has high overhead – but you can only charge for user BW • ATM is an additional network • you will have to train and pay new staff • maintain another operations center • ATM usually carries IP, not native Ethernet traffic
I W F I W F Ethernet Switch Ethernet Switch SONET RING Option 4: EoS A new choice is Ethernet over SONET/SDH (EoS) The customer’s Ethernet traffic is transported directly by SONET/SDH • You build on your existing network • You transport native Ethernet • needn’t route at network edges • maintain all Ethernet features • New SONET/SDH features make EoS highly efficient But EoS and related protocols are new technologies • You may need to upgrade existing equipment • Market hasn’t yet stabilized on one technology So you will probably need to take this course !
World’s Apart SONET/SDH is presently the most prevalent transport infrastructure Ethernet is by far the most popular user data interface So we need efficient methods for carrying Ethernet over SONET But Ethernet • comes in bursty “frames” (packets) • uses basic rates of 10, 100, 1000 Mbps While SONET/SDH • is constant bit rate • is designed for various rates such as 1.6, 2.176, 6.784 Mbps So the job isn’t easy !
Standards we will encounter IEEE 802.3Ethernet ISO 3309HDLC RFC1661PPP (ex 1548) RFC1662PPP in HDLC framing (ex 1549) RFC2615PoS (ex 1619) G.707SDH (especially the new section 11 – VCAT) G.709 OTN G.7041GFP G.7042LCAS for SDH G.7043VCAT for PDH X.85IP over SDH using LAPS X.86Ethernet over SDH using LAPS
64 – 1518 B DA(6B) SA(6B) T/L(2B) data(0-1500B) pad (0-46) FCS(4B) 68 – 1522 B DA(6B) SA(6B) VT(2B) VLAN(2B) T/L(2B) data(0-1500B) pad(0-46) FCS(4B) Ethernet frame For our purposes, “Ethernet” is any layer 2 protocol using 1 of the following frame formats :
Ethernet frame size • Minimum frame is 64 bytes • Maximum payload was 1500 bytes • and maximum frame was 1522 bytes • 802.3as lengthened maximum frame to 2000 bytes • Various physical layer modulations and framing • Rates : 10 Mbps, 100 Mbps, 1 Gbps, 10 Gbps, …
packet 1 packet 2 packet 3 packet 4 packet 1 packet 2 packet 3 packet 4 Packet to bit stream The first problem in converting Ethernet to TDM: • Ethernet consists of frames carrying packets • TDM is a continuous bit stream We can convert a sequence of packets into a bit stream by using an “idle code” For example, we can use a sequence of 1s as idle indication The appearance of a 0 bit indicates that data follows 111111111111111111111110 packet 1 0111111111111111111110 packet 2 011111111111111111111110 01111110 packet 3 01111111111111111
Packet to bit stream (cont.) How does the receiver know when to return to idle? We use a specific “flag” (HDLC uses hex 7E = 01111110) We can use the flag as the idle code as well Some implementations allow “zero sharing” But the flag must not appear in valid data! If we have access to the physical layer we can mark there (“violations”) Otherwise (we only access bits) we must disallow the idle code by replacing it with something else 01111110 01111110 01111110 packet 1 01111110 01111110 01111110 packet 2 01111110 01111110 01111110 01111110 packet 3 01111110 0111111011111101111110 packet 1 011111101111110 01111110 packet 2 011111101111110 1111110 1111110 packet 3 011111101111110
HDLC flags ISO developed High level Data Link C based on IBM’s SDLC HDLC inputs packets of bytes HDLC uses hex 7E as its idle code (“flag”) 01111110 So an idle HDLC stream repeats 7E Alternatively, 1s can be sent as idle, flags as delineators There are two methods of disallowing flags • bit stuffing (zero insertion) • byte (octet) stuffing 01111110 01111110 01111110 packet 1 01111110 01111110 01111110 packet 2 01111110 01111110 01111110 01111110 packet 3 01111110 11111111111111111 01111110 packet 1 01111110 111111111101111110 packet 2 01111110 11111111111111111101111110 packet 3 01111110
Bit stuffing / zero insertion ECMA-40 Whenever the encoder sees 5 successive 1s it appends a 0 thus there are never 6 successive 1s in the data When the decoder sees 5 successive 1s : • If the next bit is a 0 it is deleted • If the next bit is a 1 then this is the closing flag Notes: • bit stream length is no longer necessarily divisible by 8 • bit stream length is not a priori predictable • worst case expansion is 20% • encoding/decoding is easy in HW, hard in SW
Byte (octet) stuffing RFC1549 Whenever the encoder sees hex 7E It replaces it with 7D 5E Whenever the encoder sees hex 7D It replaces it with 7D 5D Optionally other codes (e.g. some under hex 20) can be “escaped” Second byte is original with 6th bit complemented (xor with hex 20) e.g. ^Q = hex 11→ 7D 31 ^S = hex 13 → 7D 33 When the receiver sees 7D xx It replaces it with the original byte (complementing 6th bit) Notes: • bit stream remains byte oriented • length expansion is typically about 1%, but can range from 0 to 100% ! (there is also a consistent overhead algorithm – but not in use) • encoding/decoding is easy in SW
flag(8) address(0/8/16) ctrl(8/16) data FCS(16/32) flag(8) HDLC framing HDLC frame is bounded by flags, and has a particular structure Many variants (SDLC, ISO, LAPB, LAPD, LAPF, LAPS, SS7, PPP-HDLC, Cisco-HDLC, etc) Address: • There may be no address (e.g. SS7 HDLC) • SDLC always had 8 bit addresses • ISO 3309 HDLC has structured multibyte address • Service Access Point Identifier (MSB of SAPI =1 may indicate broadcast/multicast) • EA=1 means 8 bit, EA=0 means extended address • C/R=1 for commands, C/R=0 for responses • The single byte hex FF is recognized as the broadcast address SAPI C/R EA EA
HDLC control HDLC networks can be configured: • Balanced – all stations have equal responsibility • Unbalanced – primary and one or more secondary stations and HDLC can operate : • Best effort (datagram) • uses Un-numbered (U) frames • Reliable (Asynchronous Balanced Mode) • uses frames with sequence numbers in control field • Information (I) frames (data + acknowledgement) • Supervisory (S) frames (only acknowledgement) The various frame types are indicated by the control field which varies widely between different protocols
HDLC FCS HDLC uses a Frame Check Sequence to detect errors The FCS is implemented as a shift-register • CRC-16 X16 + X12 + X5 + 1 • CRC-32 X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 + X2 + X + 1 Some HDLC-based protocols require 32 bit FCS others allow 16 bit but recommend 32 bit FCS
Point to Point Protocol (RFC 1661) PPP is a method for transporting datagrams between 2 peers over full-duplex, point-to-point data links • for example: short lines, leased lines, dial-up modems PPP may be used to connect hosts to routers, and routers to routers PPP is made up of 3 components: • encapsulation method for (multiprotocol) datagrams • Link Control Protocol for establishing, configuring, and testing data-link connections • Network Control Protocols for establishing and configuring different network-layer protocols PPP is a suite containing many protocols ML-PPP, PPPoE, BAP, BCP, IPCP, …
protocol(8/16) information padding Basic PPP encapsulation (RFC 1661) Encapsulation enables demuxing of different network-layer protocols Only 1 field needs to be examined for protocol determination Protocol field obeys ISO 3309 rules: • protocol value must be odd (for EA=1) • if 16-bit, then the LSB of first byte must be zero (for EA=0) PPP protocol values managed by IANA (http://www.iana.org/assignments/ppp-numbers) Padding may be used (e.g. to cause header to fall on 32-bit boundary)
flag 7E address FF ctrl 03 protocol (8/16b) information padding (optional) FCS (16/32b) flag 7E PPP using HDLC framing (RFC 1662) When using PPP over synchronous links we use HDLC-like framing 1 byte Broadcast address is used by default (users may define alternative address) Synchronous Link may be bit-oriented or byte-oriented Basic PPP encapsulation is extended by 8 bytes Bit stuffing or byte stuffing allowed Escape mechanism allows transparent transfer of control data (e.g. ^S/^Q) enables removal of spurious control data (inserted by intermediate boxes)
flag 7E address FF ctrl 03 protocol (8/16b) information padding (optional) FCS (16/32b) flag 7E RFC1662 vs. X.85 ITU-T X.85 defines IP over SDH using LAPS (will study later) Its encapsulation is similar to RFC1662(but can’t co-exist with it) Instead of the protocol ID it has a SAPI = 21 for IPv4 =57 for IPv6 The FCS MUST be 32 bits and no padding is used No special escaping is defined PPP frame 1662 flag 7E address 04 ctrl 03 SAPI (16b) IP Packet FCS (32b) flag 7E X.85
BackgroundSONET/SDH Note: For more information – see SONET/SDH course.
regenerator ADM ADM Path Termination Line Termination Section Termination Line Termination Path Termination path line line line section section section section SONET architecture SONET (SDH) has at 3 layers: • path – end-to-end data connection, muxes tributary signals path section • there are STS paths + Virtual Tributary (VT) paths • line – protected multiplexed SONET payload multiplex section • section – physical link between adjacent elements regenerator section Each layer has its own overhead to support needed functionality SDH terminology
90 columns 9 rows SONET STS-1 frame Synchronous Transfer Signals are bit-signals (OC are optical) Each STS-1 frame is 90 columns * 9 rows = 810 bytes There are 8000 STS-1 frames per second so each byte represents 64 kbps (each column is 576 kbps) Thus the basic STS-1 rate is 51.840 Mbps
270 columns … 9 rows SDH STM-1 frame Synchronous Transport Modules are the bit-signals for SDH Each STM-1 frame is 270 columns * 9 rows = 2430 bytes There are 8000 STM-1 frames per second Thus the basic STM-1 rate is 155.520 Mbps 3 times the STS-1 rate!
SONET/SDH rates STS-N has 90N columns STM-M corresponds to STS-N with N = 3M SDH rates increase by factors of 4 each time STS/STM signals can carry PDH tributaries, for example: • STS-1 can carry 1 T3 or 28 T1s or 1 E3 or 21 E1s • STM-1 can carry 3 E3s or 63 E1s or 3 T3s or 84 T1s
SONET/SDH tributaries E3 and T3 are carried as Higher Order Paths (HOPs) E1 and T1 are carried as Lower Order Paths (LOPs)
STS-1 frame structure 90 columns Synchronous Payload Envelope 3 rows Section overhead is 3 rows * 3 columns = 9 bytes = 576 kbps framing, performance monitoring, management Line overhead is 6 rows * 3 columns = 18 bytes = 1152 kbps protection switching, line maintenance, mux/concat, SPE pointer SPE is 9 rows * 87 columns = 783 bytes = 50.112 Mbps Similarly, STM-1 has 9 (different) columns of section+line overhead ! 9 rows 9 rows 6 rows section + line overhead
STM-1 frame structure 270 columns Similarly, STM-1 has 9 (different) columns of transport overhead ! RS overhead is 3 rows * 9 columns Pointer overhead is 1 row * 9 columns MS overhead is 5 rows * 9 columns SPE is 9 rows * 87 columns … Transport Overhead TOH
Xn Yn =Xn + Yn-43 Z-43 Scrambling SONET/SDH receivers recover clock based on incoming signal Insufficient number of 0-1 transitions causes degradation of clock performance In order to guarantee sufficient transitions, SONET/SDH employ a scrambler • All data except first row of section overhead is scrambled • Scrambler is 7 bit self-synchronizing X7 + X6 + 1 • Scrambler is initialized with ones A short scrambler is sufficient for voice data but NOT for data which may contain long stretches of zeros When sending data an additional payload scrambler is used • modern standards use 43 bit X43 + 1 • run continuously on ATM payload bytes (suspended for 5 bytes of cell tax) • run continuously on HDLC payloads
HOP SPE structure 2 bytes in the line overhead point to the STS path overhead POH pointer (floating) allows frequency/phase compensation (after re-arranging) POH is one column of 9 rows (9 bytes = 576 kbps)
J1 B3 C2 G1 F2 H4 F3 K3 N1 POH Path overhead POH is responsible for • path performance monitoring • status (including of mapped payloads) • trace 2 bytes are of particular interest to us: C2 is the “signal label” indicates path payload type H4 is the “multiframe indication” used by VCAT/LCAS (discussed later)
1 30 59 87 STS-1 HOP 1 column of SPE is POH 2 more (“fixed stuffing”) columns are reserved We are left with 84 columns = 756 bytes = 48.384 Mbps for payload This is enough for a E3 (34.368M) or a T3 (44.736M)
LOP VTG 1 30 59 87 2 3 4 5 6 7 1 To carry lower rate payloads, divide 84 available columns into 7 * 12 interleaved columns, i.e. 7 Virtual Tributary (VT) groups VT group is 12 columns of 9 rows, i.e. 108 bytes or 6.912 Mbps VT group is composed of VT(s) • There are different types of VT in order to carry different types of payload • all VTs in VT group must be of the same type • but different VT groups in same SPE can have different VT types A VT can have 3, 4, 6 or 12 columns
SONET/SDH : VT/VC types 4 per group 3 per group LOP 2 per group 1 per group HOP standard PDH rates map efficiently into SONET/SDH !
Payload capacity VT1.5/VC-11 has 3 columns = 27 bytes = 1.728 Mbps but 2 bytes are used for overhead so actually only 25 bytes = 1.6 Mbps are available Similarly VT2/VC-12 has 4 columns = 36 bytes = 2.304 Mbps but 2 bytes are used for overhead So actually only 34 bytes = 2.176 Mbps are available
Concatenation Payloads that don’t fit into standard VT/VC sizes can be accommodated by concatenating of several VTs / VCs For example, 10 Mbps doesn’t fit into any VT or VC so w/o concatenation we need to put it into an STS-1 (48.384 Mbps) the remaining 38.384 Mbps can not be used We would like to be able to divide the 10 Mbps among 7 VT1.5/VC-11 s = 7 * 1.600 = 11.20 Mbps or 5 VT2/VC-12 s = 5 * 2.176 = 10.88 Mbps
Concatenation There are 2 ways to concatenate X VTs or VCs: • Contiguous Concatenation (G.707 11.1) • HOP – STS-Nc(SONET) or VC-4-Nc(SDH) or LOP – 1-7 VC-2-Nc into a VC-3 • since has to fit into SONET/SDH payload • only STS-Nc : N=3 * 4n or VC-4-Nc : N=4n • components transported together and in-phase • requires support at intermediate network elements • Virtual Concatenation (VCAT G.707 11.2) • HOP – STS-1-Xv or STS-Nc-Xv(SONET) or VC-3/4-Xv (SDH) or LOP – VT-1.5/2/3/6-Xv(SONET) or VC-11/12/2-Xv (SDH) • HOP: X ≤ 256 LOP: X ≤ 64 (limitation due to bits in header) • payload split over multiple STSs / STMs • fragments may follow different routes • requires support only at path terminations • requires buffering and differential delay alignment
Contiguous Concatenation: STS-3c 270 columns … 9 rows 258 columns of SPE STS-3 9 columns of section and line overhead 258 columns * 0.576 = 148.608 Mbps 3 columns of path overhead 270 columns … 9 rows STS-3c 260 columns of SPE 9 columns of section and line overhead 1 column of path overhead 260 columns * 0.576 = 149.760 Mbps
STS-N vs. STS-Nc Although both have raw rates of 155.520 Mbps STS-3c has 2 more columns (1.152Mbps) available More generally, For STS-Nc gains (N-1) columns e.g. STS-12c gains 11 columns = 6.336Mbps vis a vis STS-12 STS-48c gains 47 columns = 27.072 Mbps STS-192c gains 191 columns = 110.016 Mbps ! However, an STS-Nc signal is not as easily separable when we want to add/drop component signals
Virtual Concatenation … VCAT is an inverse multiplexing mechanism (round-robin) VCAT members may travel along different routes in SONET/SDH network Intermediate network elements don’t need to know about VCAT (unlike contiguous concatenation that is handled by all intermediate nodes) H4
SDH virtually concatenated VCs So we have many permissible rates 1.600, 2.176, 3.200, 4.352, 4.800, 6.400, 6.528, 6.784, 8.000, …
SONET virtually concatenated VTs So we have many permissible rates 1.600, 2.176, 3.200, 3.328, 4.352, 4.800, 6.400, 6.528, 6.656, 6.784, …