why laps (x.85)

Welcome to join Tutorial

Q.7/17 Rapporteur

An Introduction to

LAPS and MSR Applications

To the March 2004 SG17 Meeting

Our Liaisons and Communications

Q.7/17

LeaderSG17

SG15

P802.17

SG13

IETF

1 、 Delay contribution, August 1998 2 、 It was acceptable by ITU-T SG7(Data network and Open System Communication) at the September meeting, 1998 3 、 X.85/Y.1321 on IP over SDH using LAPS was determined at the June 1999 meeting 4 、 Recommendation X.85/Y.1321) was approved at March 2000 meeting,then new version is available Feb. 2001

X.85/Y.1321 (IP over SDH using LAPS) milestone

1 、 IETF and ISOC 2 、 ITU-T SG15 (Optical and other transport networks) 3 、 ITU-T SG11 (Signaling requirements and protocols) 4 、 ITU-T SG13 (Multi-protocol and IP-based networks and their internetworking) 6 、 Nortel 7 、 NTT 8 、 Swisscom 9 、 Lots of email from Vendors and Carriers

X.85/Y.1321 Comments received

1 、 Simple implementation 2 、 High efficiency in the POS line card of router 3 、 Function equivalent to PPP/HDLC 4 、 Performance of Carrier concern 5 、 Compatibility with PPP/HDLC 6 、 Test equipment (share POS)

Why LAPS (X.85)

Note: PPP is widely deployed in networks around the world and has been updated and extended over the last 14 years. These slices just emphases a simple LAPS method of high-speed link (e.g. POS) and also provide compatibility with PPP/HDLC.

SDH/SONET SDH/SONET

HDLC

PPP

IP IP

PPP over SDH/SONET IP over SDH

LAPS

Why LAPS (X.85)

LineCard 0

SwitchFabric

Scheduler

LineCard 1

LineCard 6

LineCard 7

LineCard 8

LineCard 10

RE RE orLC11

The diagram of Router

Why LAPS (X.85)

O/ESTM-16c

TransceiverPOS

FramerNetwork

Processor I/F

POS Line Card Memory SwitchFabric

16 x 16

O/EPOS

Framer I/F

Memory

STM-16cTransceiver

POS PHYPOS PHY

Routing Engine

POS Line Card

NetworkProcessor

POS Line Card

SPI-4.2SPI-4.2

Why LAPS (X.85)

RoutingEngine

SDH/SONET

HDLC

PPP,LCP,IPCP

IP

OSPFTCPUDP

BGPRIPSNMP

Local node

Adjacent Node

Filter Function

POS PHY/Utopia3 Reference Point

Fwd/Rcv to/fromForwarding

Engine

LCP

Softw

areH

ardware

Protocol processing of signaling and Traffic plane

Why LAPS (X.85)

• The major objective of X.85 is to remove PPP protocols including LCP and IPCP in the case of POS.

•LCP contains 10 configuration packets,16 events, and 12 actions.

Why LAPS (X.85)

Protocol

8/16 bits Padding

RFC 1662 frame

Flag

01111110

FCS

16/32 bits

Address

11111111

Control

00000011

Flag

01111110

RFC 1661 frame

X.85 frame

X.86 vs. RFC 2615 (frame)

PPPPPP

PDU

SAPI

16 bits

Flag

01111110

FCS

32 bits

Address

00000100

Control

00000011

Flag

01111110

IPv4 and IPv6

PDU

Why LAPS (X.85)

X.85 vs. RFC 2615, specifications including functions and related Network management

RFC 2615 ： RFC 1661

RFC 1662

RFC 1570

RFC 1547

RFC 1340

SNMP & MIB

X.85

SNMP & MIB

Why LAPS (X.85)

LAPS or POS HDLC Framer/Deframer functions:

Insertion of HDLC frame into the SPEFraming, Inter-frame fill and transmit FIFO error recovery. Scrambling (X**43 +1),Transparency processinggenerate a 16/32 bit FCS.

Extraction of HDLC frame, Transparency removal, De-scrambling (if enable), FCS error checking, Optional delete the HDLC address and control fields.

T

R

Why LAPS (X.85)


Why LAPS (X.85)

Comparison of Protocol states ：RFC 2615 ： 2+137 ， LAPS ： 2

Why LAPS (X.85)


Why LAPS (X.85)

RFC 2615 （ PPP/HDLC ） LAPS

Protocol encapsulation yes yes

Inter-frame fill yes yes

Scrambling yes yes

Transparency yes yes

FCS yes yes

Link status monitoring Yes yes

Configuration Req./Ack/Nak yes （ padding function ）Terminate Req./Ack yes （ but it is seldom used ）Protocol Reject yes （ but it is seldom used ）Echo Req./Reply yes yes in SDH/SONET

Discard Req. yes （ but it is seldom used ）

Why LAPS (X.85)


Why LAPS (X.85)

Input stream

schedulerparsing

Search & update

Receive editor

Queue mgnt.

Output

Stream

scheduler

Queue mgnt.

Sending

editorCPU I/F

System I/F

Fabric I/F

Switch Fabric

Framer/D

eframer

SSRAM SDRAM

SDRAM

Pre-search

queue

Statistics & internal registers

CPU

The Diagram of Network Processor

Why LAPS (X.85)

L1

L2

L3

L4

L5L6

L7

Physical LayerPhysical Layer

NetworkNetworkTransportTransportSessionSession

Presentation

ApplicationApplication

HDLCHDLC

Open System Interconnection

L2 PPPPPP 、、 LCP LCP 、、 IPCPIPCP Intermediate system ， 10 bytes

Intermediate system ， 40-1600 bytes

End system

Why LAPS (X.85)

RFC 2615(PPP/HDLC) LAPS Cell based

MPS/mPS 1600/10=160 1600/40=40 1

Latency NP NP

Latency variance 4 times － good

Packet loss 4 times － very low

Capability of

Jumbo payload

processing relative lower relative power good

Congestion processing capability low middle relative high

QoS 3 times lower normal good

Why LAPS (X.85)


Why LAPS (X.85)

Why LAPS (X.85)

LAPS

LAPS

LAPS PPP/HDLC

GbEPPP/HDLC

PPP/HDLC GbE

Node1

Node2 Node3

Node4

Node5

SDH/SONET

SDH/SONET

HDLCPPPIP IP

PPP over SDH/SONET IP over SDH

LAPS

How LAPS compatible with PPP/HDLC

SDH/SONET

LAPS=HDLC

PPPIP

PPP over SDH using LAPS

Why LAPS (X.85)

Protocol

8/16 bits Padding

RFC 1662 frame

Flag

01111110

FCS

16/32 bits

Address

11111111

Control

00000011

Flag

01111110

RFC 1661 frame

X.85 frame

X.86 vs. RFC 2615

PPPPPP

PDU

SAPI

16 bits

Flag

01111110

FCS

32 bits

Address

00000100

Control

00000011

Flag

01111110

IPv4 and IPv6

PDU

Why LAPS (X.85)

When the PPP is used to be encapsulated via SAPI for the compatibility with RFC 2615, it is noted:

(1)Both FCS-32 and FCS-16 can be set by provisioning and is not negotiated. The 32-bit FCS must be used for all SDH rates. For STM-1c/VC-4 only, the 16-bit FCS may be used, although the 32-bit FCS is recommended.

(2)Regarding the path signal label (C2) of SDH, for compatibility with RFC 2615, the signal label value of (x43 + 1) scrambling is changed from 24 (18 hex) to 22 (16 hex). Additionally, the LAPS does also provide the signal label value 207 (CF hex) to indicate PPP without scrambling.

(3)The data link will be operated as RFC 2615 defines and the Address field is set to “11111111”, the padding field followed information field and the functions of Link Control Protocol and Network Control Protocol will be included.

Why LAPS (X.85)


Why LAPS (X.85)

Testing equipment 1 、 Smartbits are used to throughput 2 、 RouterTest/Adtech is used to traffic and routing protocols

Why LAPS (X.85)

X.86 (Ethernet over SDH/SONET) introduction

1 、 Delay contribution from May 1999 2 、 It was acceptable by ITU-T SG7(Data network and Open System Communication) at the June meeting, 1998 3 、 X.86 on Ethernet over LAPS was determined at the March 2000 meeting 4 、 Recommendation X.86 on Ethernet over LAPS (TD 2046/Rev.1) was approved at Feb. 2001 meeting, ten months earlier than that of GFP

LAPS (X.86) milestone

SONET/WDM

GE

2.5GbpsSDH

155MbpsSDH

155Mbps

EthernetEthernet

ITU-T X.86(Target at Ethernet over SDH/SONET)

2.5Gbps

FE

EOS EOS

GE

1

3 2

EOS

EOS

EthernetEthernet

EthernetEthernet

EthernetEthernetEthernet

GE

1.Telecom based Switch2.Datacom based SDH/SONET3.2-port small box solution

LAPS (X.86), three types of application

Latency Variance Computation

Ethernet MAC -15μs

Rate Adaptation, Buffer -15μs

LAPS mapping, Buffer -15μs

LAPS CRC, Buffer -15μs

-----------------------------------------

Latency Variance Total:-60μs

GE on GE switch -4μs

The competitive advantages of X.86

• Remote Trail Performance Monitoring

• Remote Fault Indication

• IEEE802.3x – Active Flow Control in Burst Traffic Condition

• Low Price and Ease of Use (Compared to LANE)

• Low Latency and Low Latency Variance

• 1+1 redundancy based Ethernet and Gigabit Ethernet service

• Target at existing telecom transport resources

IFG Preamble+SFD

802.3 MAC Frame

12 Bytes

8 Bytes 64 Bytes

=84 Bytes

Flag Addr Cont SAPI 802.3 MAC 32-Bit CRC Flag

10

=84 Bytes

1 1 1 2 64 4

Flag

1

Time Fill

X.86 does match Ethernet and Gigabit Ethernet very well

COREHEADER

PAYLOADAREA

16-bit PAYLOADLENGTH INDICATOR

cHEC(CRC-16)

CLIENTPAYLOAD

INFORMATIONFIELD

OPTIONALPAYLOAD FCS

(CRC-32)

PAYLOADHEADERS

(4-64 BYTES)

Octet

1

2

3

4

Bit

1 2 3 4 5 6 7 8

PLI <15:08>

PLI <07:00>

cHEC <15:08>

cHEC <07:00>

Octet Transmission

Order

Bit Transmission Order

Extension Header Field

tHEC

eHEC

1 2 3 4 5 6 7 8

Octet Transmission

Order


Octet

2

2

Bit

Type

2

0 to 60

5

6

7

8

9

.

.

.

1 2 3 4 5 6 7 8

PTI EXIPFI

Bit

Bit

UPI

15 14 13 12 11 10 9 8

7 6 5 4 3 2 1 0

5

6

OctetTransmission

Order


(1)Payload

(2)Payload Header

(3)Optional Payload FCS

(4)PLI value

(5)cHEC computation

Understand GFP

•HEC inherits from ITU-T Rec. I.432 ， Octet based spec.

• ATM is L2/L3 technologies, based on connection and fixed packet size (cell), IP as a ATM client is flexible rate for the IP over ATM applications in the most case; GFP is L1/L2 technologies, based on connectionless and variable packet size. For the L1-GFP, FE/GE as a GFP client is rigid rate for the Ethernet over SDH applications in the most case

• In terms of PDH(E1/T1/E3/E4), Jumbo Payload size of IPv6 can be greater to 64Kbits length due to GFP-PLI is 2-Octet definition (216bits=64Kbits=8Kbytes) ？ If PLI is changed to 3-octet or more, how to keep compatibility with existing GFP standard

• Flow control ？ Rate adaptation?

Understand GFP

Why Flow control? Why Rate adaptation?

(1)FE/GE Bandwidth≠VC or VCs concatenation Bandwidth

(2)No difference is applied for the two time-slice (TS) if Ethernet data stream is mapped into VC overhead or/and VC payload during two different time-slice

Understand GFP

Real-time

VC overhead

VC payload

Mapping octet by octet

TS1 TS2

•Issue of tiny-frame (7 bytes), Client Signal Fail (LOS of Client Signal and Loss of Character Synchronization) ？•4-octet idle issue ？

Understand GFP

L1

L3

L4

L5L6

L7

NetworkNetworkTransportTransportSessionSession

Presentation

ApplicationApplication

Physical LayerPhysical Layer

Open System Interconnection

L2 Intermediate system ， 7 bytes

Intermediate system ， 40-1600 octets

End system

tiny-frame issue for IPv4 over SDH using GFP(1)

GFPGFP

Understand GFP


Framer 网络处理器背板适配

POS-PHY bus/SPI-4.2 bus

155M POS ---825M

622M POS --- 1650M

2.5G POS --- 32100M,6450M

Framer 网络处理器背板适配Framer 网络处理器背板适配Framer 网络处理器背板适配Framer 网络处理器背板适配Framer Network

Processor

Backplane

Adaptation

Routing and signaling

Line Card

Understand GFP

GFP LAPS Cell based

MPS/mPS 1600/7=228 1600/40=40 1

Latency variance great middle little


Understand GFP

MPS: Maximum packet Size, 1600 octets specified by IETF

mPS: Minimum Packet Size , 40 octets specified by IETF

Mapping relationship and timing,FE/GE is mapped into GFP, LAPS and RPR(LAPS/GFP)

Understand GFP

4-octet idle issue

IdleIdle Idle PLIeHECCID+Spare

tHECType

cHECPLIIdleIdle

IFG Preamble+SFD

4 22 2 2

812

4 4 2 2

64-1518

Idle

4

IFG Preamble+SFD

812

44 2

Ethernet Frame

GFP frame

Real Time

FCSFCS

GFP Payload

Case 1 - Octets Mapping of Ethernet using GFP

Understand GFP

64-1522 if VLAN

Flag

X.86 Frame

IFG Preamble+SFD

812 64-1518

IFG Preamble+SFD

812

Ethernet Frame

Real Time

Flag AddrFlagFlag

11 10 1 1N 11

Addr.

1

Ctrl SAPI FCS

4LAPS Payload2

Flag

12 3

45 6

Case 2 - Octets Mapping of Ethernet using LAPS

LAPS & GFP

68-1522 if VLAN

LAPS & GFP

RPR idle format

Idle Idle

GFP frame

RPR Frame

IFG Preamble+SFD

812 64-1518

IFGPreamble+SFD

812Ethernet Frame

Real Time

IdleIdle Idle PLIeHECCID+Spare

tHECTypecHECPLIIdleIdle

4 22 2 24 4 2 2

Idle

4 44 2

FCSFCS

Ring Control

2

DA

6 6

SA

2

Protocol Type

2

Header CRC FCS

16RPR Payload

GFP Payload

Case 3 - Octets Mapping of Ethernet/RPR/GFP

1

23

45

67

8

9

10

44

64

? Packet Loss

Timing border

1 2 3 4 65 7 8 9 10

Delay1 2 3 4 65 7 8 9 10

No Delay

Variable Variable Variable

Variable

Next frame

4 4

LAPS & GFP68-1522 if VLAN

LAPS & GFP

Flag Flag

GFP frame

RPR Frame

IFG Preamble+SFD

812 64-1518

IFG Preamble+SFD

812Ethernet Frame

Real Time

FlagFlag FlagSAPICtrlAddrFlagFlag

1 111 N 2

Idle

4 11 1

FCSFCS

Ring Control

2

DA

6 6

SA

2

Protocol Type

2

Header CRC FCS

16RPR Payload

LAPS Payload

Case 4 - Bytes Mapping of Ethernet/RPR/LAPS

1

23

45

67

8

9

10

11

64

Good No Packet Loss

Timing border

1 2 3 4 65 7 8 9 10

Delay1 2 3 4 65 7 8 9 10

No Delay

Variable Variable Variable

Fixed

N

Flag

N

Next frame

68-1522 if VLAN

GFP LAPS/X.86 Percentage

64bytes 10.520 µs 9.658 µs 8.9%

1518bytes 203.620 µs 133.967 µs 51.9%

9.6Kbytes - 769.567 µs

Comparison of Measurement

LAPS & GFP

• Flow-control and rate adaptation are very useful for BW mismatch between Ethernet and SDH VC (or concatenation) and time-slice difference between VC overhead and VC payload

• Application of Both SDH and PDH(E1/T1/E3/E4) for LAPS, Both SDH and PDH(DS3) for GFP

• High efficiency

• LAPS is compatible with POS and PPP/HDLC

• LAPS Idle(Flag) has good performance for line-speed Ethernet over SDH/SONET applications

• X.86 was approved ten months earlier than that of GFP

Advantage of using LAPS

Disadvantage of LAPS and PPP/HDLC

(1) Escape Code

LAPS & GFP

An Introduction to MSR Applications

•What is MSR?•Why MSR?•MSR Scope•Multi-service capabilityMulti-service capability

TCEFE

GEMSR

FE (1)TCE (1)

FE (3)

TCE (1)

FE (4)FE (2)

TCE (1)

MSR (2)

TCE (2)

MSR(3)

MSR (1)

TCE (1)

FE (5)

TCE (2)

GE

TCE (1)

TCE (3)

First Working RingFirst Working Ring

Second Working Ring

Aggregate Pipe

TCE POS

TCE

POS

Data Node 1

Data Node 2

Data Node 3

Data Node 4

Data Node 5

Data Node 6

TCE (1)

MSR (2)TCE (2)

What is MSR(1)

Station A

Big pipe: AggregateSmall pipe: tributary

(just like PVC)

Station B

What is MSR(2)

• Focus on Metro

• Sync. to async., TDM to packet, Physical transmission from SDH/SONET to MAC, High-order VC and Lower-order VC to tributary (packet)

• MSPP/MSTP from TDM based to packet based

• Push multi-service transport issue to LLC(L2)

Basic Consideration(1)

• Differentiated SLA, controllable and configurable service operation

• Static and dynamic resource management

• Both connection and connectionless

• Bridge and back-to-back connection between MSR/RPRs

• Lower cost and little maintenance

Basic Consideration(2)

differentiates RPR transport capabilities and provides multi-congeneric-service and multi-heterogeneous-service transport including Ethernet, Gigabit Ethernet, FR, G.702 PDH circuit -- Synchronous and asynchronous circuit transport, Video signal, voice-band signal, Digital channel etc.

Why MSR(1)

Differentiates RPR ring protection function and provides service (or tributary) based standby (protection) of 1+1, 1:1, and 1:N models within 50 ms.

Why MSR(2)

Reassembly a single packet based multicast and broadcast of RPR to form service (stream) multicast and broadcast capabilities, and provide Service (or tributary) based multicast and broadcast.

Why MSR(3)

Adding bandwidth management function for each service (tributary) and provides service bandwidth management with either symmetry or asymmetry.

Why MSR(4)

Adding bandwidth merging function for congeneric-service (congeneric-tributary) and provides tributary merging with either symmetry or asymmetry.

Why MSR(5)

Adding the simple security filtering function for each tributary service and provides line-rate filtering to monitor and manage service security.

Why MSR(6)

Adding the performance management function for each tributary service and provides tributary performance monitoring in 15-minute and 24-hour.

Why MSR(7)

•QoS Guarantee

•Customers separation

•Addresses separation

•Topologies separation

Why MSR(8)

Topology supported

•Two fiber ring

•Link

•Broadcast topology

Why MSR(9)

Dynamic resource management

Static resource management

Tributary transport

Why MSR(10)

Next job

S[62] S[8] S[7] S[6] S[5]

S[0] S[1] S[2] S[4]

WEST PHY

EAST PHY

MACDataReq. Ind.

RPR MAC client: X.87 layer

Ringlet 1

Ringlet 0

X.87 layer client

Reference Point T1/T2

Reference Point G1/G2

X.87

XP UNACKData Req. Ind.

MACCtrlReq. Ind.

X.87 scope

SDH/SONET

RPR-MSR protocol stack

RPR

X.87

GFP/HDLC LAPS

MSR

Client

IP

RPR MAC

GFP/HDLC LAPS

Ethernet

LAPS

SDH/SONETSDH/SONET

IP

Ethernet over SDH/SONETIP over SDH

X.85

X.86 GFP

LAPS GFP/PPP

LLC

IP

SDH/SONET

RPR-MSR

RPR

X.87

GFP/HDLC LAPS

MSREthernet

Multi-serv.

IP

Layered Model (1)

Layered Model (2)

802.3 PHY

802.3 MAC-MSR protocol stack

X.87

802.3 MAC

MSR

Multi-service

IPOther

Reference Point G1/G2

RPR 和 IEEE 802.3MAC

X.87 protocol

L3 packet forwarding

Reference Point T1/T2

TCE(2)Ethernet

GETCE(1)

VLANCS & NMMPLS

Layered model of Multi-service node

Link+ADM

MSR node

MSR node

MSR node

MSR node

MSR node

Agg Agg

Trib

Trib

Broadcast

MSR node

MSR node

MSR node

MSR node

MSR node

Agg.

Agg.

MSR node

Agg.

Agg.

Agg.

Differentiate Differentiate RPR (1)RPR (1)

Features RPR+MSR RPR

Operation mode

MAC+LLC MAC

Supported tributary service

multi-congeneric-service and multi-heterogeneous-service transport including Ethernet, GE, FR, G.702 PDH circuit, Video signal, voice-band signal, Digital channel etc.

Class A/B/C ， but does not support multi-congeneric-service transport within a station


Multicast and broadcast

Based on packet and tributary service,support multi-congeneric-service within a station

Based on packet

Protection 1+1,1:1 and 1:N standby, support multi-congeneric-service within a station

Station based protection switch



Topology Two-fiber ring, link, broadcast

Two-fiber ring

Bridge across a ring

802.1 Bridge or back-to-back connection, regeneration of service tributary improves tributary QoS

802.1 Bridge



Link address Global MAC address or local MAC address

Global MAC address

Bandwidth management

Support -


Features RPR+MAC RPR

Security filtering

Support -

Asymmetrical service

Support -


Features RPR+MAC RPR

Performance monitoring ，Loopback test

Performance monitoring andLoopback test for tributary

Loopback


Access MSR

MAN/STM-64

Backbone

Applications

Backbone MSR

Access MSR

Applications: POP Interconnect

POS/EOS

RPR2X2.5 Gbps

STM-162.5 Gbps

RPR+MSR2X2.5 Gbps

Further study in Q.C/17 (old Q.7/17)

• Maintenance of X.85/Y.1321 and X.86/Y.1323, Update and extension of X.87/Y.1324;• Progress draft Recommendation X.msr, including associated Ethernet/Gigabit Ethernet/10G Ethernet aspects;• Develop Requirements for MSDN, areas of study and development include: - Identification of market needs - architectural considerations, for L2 data networks; - multi-service multicast aspects; - Ethernet UNI and NNI aspects.• Enhance existing packet protocols or, if required, develop new packet protocols to support the developed MSDN requirements, including service mechanisms;• Develop associated MIBs (Management Information Base) to support item (iv);

why laps (x.85)

Documents