9370_ip_transport_(june_2012)_

UA08.1 Deep Dive9370 IP Transport Features

June 20, 2012

All Rights Reserved © Alcatel-Lucent 20092 | May 2011

9370 IP Transport Feature List

Feature ID 9370 IP Transport Feature Name

79364 Bidirectional Forwarding Detection (BFD)

82733 IuPS UP IP Subnet Reduction to 16 @

110760 CP Path Diversity

110761 Multi-Homing on 9370 RNC

114393 LAG Support on 9370 RNC

111472 IuFlex Pool support of 24 CNs Nodes

117004 Support of 3GPP R8 S12 interface on 9370 RNC

79364 – IP UTRAN – Bidirectional Forwarding Detection (BFD)


Feature Background

Bidirectional Forwarding Detection (BFD): Standard mechanism (IETF RFC) to detect connectivity failures between two adjacent forwarding engines.Provides failure detection of interface, link and (to some extent)

forwarding engine between two routing entity. Current technique to detect connectivity between 9370 and Next

Hop Router (NHR) based on ICMP Ping: Failure detection < 4 seconds Failure recovery < 5 second Proprietary ICMP solution (may be interpreted as DOS attack by

NHR) BFD introduction on 9370 provides:

Failure detection ~300 ms Failure recovery < 1 second Standardized IETF approach

Enhances 9370 carrier grade capability by reducing local fault detection times via a standardized technique.


Feature Overview

GigE1

GigE2

9370

PDR

BFD Session 1

CP

BFD Session 2

IP Network

FEATURE DESCRIPTION•Provide for L3 failure detection between 9370 and NHR

•Supported on IuB, IuCS, IuPS & IuR (CP/UP)

•No Capacity Degradation (< 0.005% BW)

Integrated with PDR framework 1 BFD Session per PDR NH

FEATURE VALUEReduced L3 failure detection time; in sub-second range (recovery < 1 second)

Based on IETF RFC 5880 & 5881

DEPENDENCIES NHR must support (asynchronous mode) BFD

4 Port GigE on 9370 (not applicable to ATM)

VR

Protected Default Route (PDR)0000 NH1 metric 10 PDR active path NH2 metric 20 PDR alternate path


Additional Details

None of the enumerated restrictions are an issue in the AT&T deployment

# Aspect Notes

1 ICMP Heartbeat & BFD can coexist

on 9370

Both can not be active under same VR (same

Protected Default Route, 0.0.0.0)

2 BFD supported only on static

default routes (0.0.0.0 route).

Not supported on other routing protocols or over

other best match routes

3 9370 supports up to 48 BFD

sessions (12 VRs with 4 NHs per

PDR).

4 Asynchronous mode support, as

specified in the IETF RFC 5880

No “demand mode” support (not an issue in

AT&T)

5 UDP encapsulation for the single

hop IP connectivity detection

As specified in IETF RFC 5881 "BFD for IPv4 and

IPv6 (Single Hop)”.

6 Authentication functionality not

supported.

Minimal risk with single hop (TTL value, TTL =

255).

7 BFD session can be

administratively “locked” per NH

8 Protected path can be at the port

level or VLAN

LAG is also supported


Ethernet Packet format and BFD Session State Machine

UDP8

IP20

Eth tail4

BFD Control packet24 bytes

Eth hdr (+VLAN)14 (+4)

Ethernet payload

Ethernet Frame

RNC NHR

DOWN

INIT UP

UP, ADMIN DOWNDOWN

ADMIN DOWN, TIMER

DOWN INIT, UP

ADMIN DOWN, DOWN, TIMER

INIT

INIT, UP

Encapsulated in UDP:• Dest UDP port 3784• Source UDP port in

range of 49152 to 65535

3) DOWN entered when message exchange fails or remote end signals DOWN state/

1) Initial state: DOWN or INIT

2) Moved to UP when BFD control packet received with State field (remote session state) in INIT/UP

1) Initial state: DOWN or INIT


BFD Session - Normal Operation

NHR 19370

BFD Control

BFD Session

Control Packet

9370 Variables

Session State: UP

Required Min Rx Interval: 100 msDesired Min Tx Interval: 100 msDetection Multiplier: 3

Negotiated Tx Interval: 200 msNegotiated Rx Interval: 100 msRemote Detection Multiplier: 3Failure Detection Time: 300 ms

Last Local Diagnostic Code: --Last Remote Diagnostic Code: ---

Control Packet

Control Packet

Control Packet

Control Packet

100 ms

100 ms 200 ms

BFD Session

BFD Session

NHR Variables

Session State: UP

Required Min Rx Interval: 200 msDesired Min Tx Interval: 100 msDetection Multiplier: 3

Negotiated Tx Interval: 100 msNegotiated Rx Interval: 200 msRemote Detection Multiplier: 3Failure Detection Time: 600 ms

Last Local Diagnostic Code: --Last Remote Diagnostic Code: ---

1) Tx/Rx activity timers negotiated at starup (not shown).

2) Local & Remote end running in asynchronous mode.

3) When each receives packets from its peer, all is well, and no timers pop.


BFD Session - Failure Detection

9370

PDR BFD Session

9370 Local variables:SessionState: UPRemoteSessionState: UP

RequiredMinRxInterval: 100 msRemote DesiredMinTxInterval: 50 ms

Negotiated Rx Interval: 100 msRemote Detection Multiplier: 3Failure Detection Time: 300 ms X

X

XPath1 Down

Control Packet

Control Packet

Control Packet

Control Packet

300 ms

.

.

.

Control Packet

NHR 1

BFD Session

1) Only the 9370 detection is presented. The same procedure applies to both directions.

2) Local Detection Interval = Greater of ( RequiredMinRxIntercal and Remote Desired TX Interval ) X Remote DetectMult

= Greater of ( 100 ms and 50 ms ) x 3 = 100 ms x 3 = 300 ms


PDR detection & recovery times (ICMP vs BFD)

ICMP Heartbeat BFDDetection Recovery Detection Recovery

Port, Link, Card

failure

insignificant < 1 second insignificant [1] < 1 second

L3 Routing fault

< 4 seconds < 5 seconds

300 ms [2] < 1 second

[1] Detection and recovery times for Port, Link and Card failures under BFD are identical to ICMP; the detection for these types of failure is common for BFD and ICMP Heartbeat under the PDR framework.

[2] The 300 ms detection time assumes a Negotiated Rx Interval of 100 ms and a remote multiplier of 3.

• With BFD, maximum IP transport outage time may be reduced from 5 seconds to less than 1 second for L3 routing local faults.

• Upper layer timers can also be readjusted to be more reactive.


BFD Parms

Name Meaning Units

1 requiredMinRxInterval

(minRxInt)

• Minimum time interval between received BFD control packets that local system capable of supporting.

• Negotiated between local/remote peers

DECIMAL (100..65535),

DEFAULT = 100 msec

2 desiredMinTxInterval

(minTxInt)

• Minimum time interval that local system would like to use when transmitting BFD control packets.

• Negotiated between the local and remote peers.

DECIMAL (100..65535),

DEFAULT = 100 msec

3 detectionMultiplier

(mult)

• Number of sequentially missed BFD control packets before remote peer transitions BFD state to a Down session state.

• NegotiatedTxInterval, multiplied by this value, provides the detection time that the remote peer uses to determine its failure detection time.

DECIMAL (1..255), DEFAULT = 3


Migration from ICMP Heartbeat to BFD detection

9370GigE

GigE

VRIP Network

NHR

NHR

CS

Core

PS

Core

DRNC

NodeB

PDR

OMC

ICMP or BFD

Multi-step process:

1. Delete ICMP on 9370 (and optionally on NHR)

2. Add BFD on 9370 and NHR

No traffic outage during migration from ICMP Heartbeat to BFD.

82733 IuPS UP IP Subnet Reduction to

16 @


Iu-PS UP IP @ subnet reduction to size 16 - Overview

FEATURE DESCRIPTION• Augments UA07 feature 82732, by

further reducing number of IP addresses exposed by the 9370 on the Iu-PS User-Plane from 64 to 16 (i.e. reduce subnet /26 to subnet /28)

IP 9370

IuPS

RAB(40 IP@)

TMU

PC-NAT

OMU

PMC-M

“Internal Traffic”

IuPS “uplane” subnet is externally visible

DEPENDENCIES

• Only supported with 9370s equipped with DCPS FPs (100% penetration in AT&T)

• Applies to 4pGigE card on the 9370

FEATURE VALUE

• Minimizes number of externally visible IP @ required by 9370 for Iu-PS User Plane.

• Allows operators to optimize IP addressing plans by reducing the number of IP @ to be reserved for each 9370.

VR

UDP-NAT

/-size #IP@/25 128/26 64/27 32/28 16/29 8/30 4

A reminder on subset sizes


Architecture

RAB RAB

PC PandaFP GA

RAB RAB

PandaFP GA

RAB RAB

PandaFP GA

•4pGe

•IP@ 1 •IP@ 2 •IP@ n

PC PC

When configured with /26 subnet; IuPS UP IP addresses are assigned to each PMC-RAB

When configured with /28 subnet; one IuPS UP IP address is assigned per DCPS card

•16pOC3

•IP@ 1 •IP@ 6 •IP@ 7 •IP@ 13 •IP@ 34 •IP@ 40

…

•IP@

•IP@ from /26 IuPS UP subnet

from /28 IuPS UP subnet

•/26 => /28• subnet

Forwarding

performed by FPGA

under control of PMC-PC.


Migration from /25, /26 to /28

Migration from a /25 or /26 subnet to a /28 subnet: UA08 software activation:

After UA08 activation, subnet remains unchanged; IuPS UP subnet size should be /25 or /26.

Configuring /28 subnet: IuPS UP subnet size is changed to /28 (subnet mask: 255.255.255.240) in the

configuration model. Initialization software uses subnet size as trigger to assign IuPS Uplane

addresses to new termination points on the PMC-PCs.

Note: Changing the subnet size causes all APs to reset; service outage is expected;

/25 /26 /28

PSFP RAB RAB Not Supported

DCPS RAB RAB PC / FPGA

IP Address assigned to:

A semantic check prevents configuring the /28 subnet under IuPS UP interface when the 9370 is PSFP based.


PMC-PC IP Address Assignment

• uplane/Iups subnet of x.y.z.n/28

• n = 0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224 and 240

Card Number

IP Address For Example(subnet =

172.1.1.80)0 CP Card

1 CP Card

2 x.y.z.n+1 172.1.1.81

3 x.y.z.n+2 172.1.1.82

4 x.y.z.n+3 172.1.1.83

5 x.y.z.n+4 172.1.1.84

6 x.y.z.n+5 172.1.1.85

7 x.y.z.n+6 172.1.1.86

8 OC3 Card

9 OC3 Card

10 x.y.z.n+7 172.1.1.87

11 x.y.z.n+8 172.1.1.88

12 x.y.z.n+9 172.1.1.89

13 x.y.z.n+10 172.1.1.90

14 Gige Card

15 Gige Card

Example configuration:• Subnet @ =

172.1.1.80• Broadcast @ =

172.1.1.95• Interface @ =

172.1.1.94vr/<n> pp/<port> ip logicalIf/172.1.1.94, netmask 255.255.255.240

110760 CP Path Diversity


Overview

FEATURE VALUE Increased control plane resiliency on IuCS/IuPS

interfaces Only 50% of signalling traffic is impacted in case

of NHR failure (previously up to 100%) Half of SCTP associations remain available to

support CP traffic

FEATURE DESCRIPTION Introduces path diversity between 9370 and

directly connected NHR for control plane on the IuCS, IuPS and IuR interfaces

DEPENDENCIES4pGigE boards

9370GigeCard

GigeCard

VRIP Network

NHRCS

Core

PSCore

DRNC

PDR

NHR


3G-MSC

Egress Path Diversity

IP Network

PDC2SCTP EP1

PDC7SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

PDC3SCTP EP2

PDC6

SCTP EP3

VR1

NHR A

NHR B

3G-MSC

ESC 1

ESC 2

WSS7 1SCTP EP1

WSS7 2

SCTP EP2

M3UA

M3UA

20.1.1.1

21.1.1.1

NHR D

NHR C

11.1.1.2

11.1.1.1

10.1.1.1

10.1.1.2

9370 Static Routes Configuration:

Protected Default Route0000 NH1 metric 10 PDR active path

NH2 metric 20 PDR alternate path

More specific route to reach subnet 20.1.1.0:20.1.1.0 NH1 metric 10 active path

More specific route to reach subnet 21.1.1.0:21.1.1.0 NH2 metric 10 active path

By configuring more specific routes, egress Control traffic can be sent from the 9370 over two distinct GigE interfaces and routing paths.

The diverse paths (with same NHs as PDR NHs) are protected under the PDR framework.

Routing Path 1

Routing Path 2


Egress Path Diversity – Under IP Network failure condition

IP Network

PDC2SCTP EP1

PDC7

SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

PDC3SCTP EP2

PDC6

SCTP EP3

VR1

3G-MSC

ESC 1

ESC 2

WSS7 1SCTP EP1

WSS7 2

SCTP EP2

M3UA

M3UA

10.1.1.1

10.1.2.1

1.1.1.10

1.1.1.9

1.1.1.1

1.1.1.2

Path Diversity protects against extended IP routing failures that could occur on network side of the adjacent router or beyond (not directly visible on the 9370).

This would typically require some sort of double-fault (or procedures fault) condition.

In current PDR configuration (without path diversity, all egress traffic routed based on protected default route 0.0.0.0), 100% of control traffic could be impacted when such failures occur.

With Path Diversity, 50% of the control traffic is preserved; only half of SCTP associations are impacted.

Routing Path 1

Routing Path 2

NHR A

NHR B

NHR D

NHR C


Ingress Path Diversity

IP Network

PDC2SCTP EP1

PDC7SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

PDC3SCTP EP2

PDC6

SCTP EP3

VR1

3G-MSC

ESC 1

ESC 2

WSS7 1SCTP EP1

WSS7 2

SCTP EP2

M3UA

M3UA

20.1.1.1

21.1.1.1

11.1.1.2

11.1.1.1

10.1.1.1

10.1.1.2

9370 Subnets Configuration:

Subnet 1: 10.1.1.0 /29 with 8 IP addressesSubnet ID: 10.1.1.0Broadcast: 10.1.1.7Interface: 10.1.1.6

Available addresses (10.1.1.1-5)

Subnet 2: 11.1.1.0 /29 with 8 IP addressesSubnet ID: 11.1.1.0Broadcast: 11.1.1.7Interface: 11.1.1.6

Available addresses (11.1.1.1-5)

Subnet 1

Subnet 2

• By partitioning 9370 SCTP end points under two logical subnets, possible to route from MSC using two independent paths.

• Each subnet on the 9370 allows for 5 usable IP addresses, where each IP@ can be associated with an SCTP End Point (8 SCTP End Points in 10 DCPS 9370 configuration)

NHR A

NHR B

NHR D

NHR C

/-size #IP@/25 128/26 64/27 32/28 16/29 8/30 4


Ingress Path Diversity - Under IP Network failure condition

IP Network

PDC2SCTP EP1

PDC7

SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

PDC3SCTP EP2

PDC6SCTP EP3

VR1

3G-MSC

ESC 1

ESC 2

WSS7 1SCTP EP1

WSS7 2

SCTP EP2

M3UA

M3UA

20.1.1.1

21.1.1.1

11.1.1.2

11.1.1.1

10.1.1.1

10.1.1.2

Subnet 1

Subnet 2

Similar to egress path diversity, upon extended IP routing failures 50% of the control traffic is preserved.

NHR A

NHR B

NHR D

NHR C


Etherent/LAN/VLAN Counters

Counter number

Counter name Granularity

#20301 VS.unknownVlanId Ethernet Port#20302 VS.rxFrames Lan or Vlan#20303 VS.txFrames Lan or Vlan#20304 VS.rxBytes Lan or Vlan#20305 VS.txBytes Lan or Vlan#20306 VS.rxDiscFrames Lan or Vlan#20307 VS.txDiscFrames Lan or Vlan#20311 VS.txBytesDp0 Ethernet Port / Emission Priority #20312 VS.txBytesDp1 Ethernet Port / Emission Priority#20313 VS.txBytesDp2 Ethernet Port / Emission Priority #20314 VS.txBytesDp3 Ethernet Port / Emission Priority #20315 VS.txFramesDp0 Ethernet Port / Emission Priority #20316 VS.txFramesDp1 Ethernet Port / Emission Priority #20317 VS.txFramesDp2 Ethernet Port / Emission Priority #20318 VS.txFramesDp3 Ethernet Port / Emission Priority #20319 VS.txFramesDiscDp0 Ethernet Port / Emission Priority

#20320 VS.txFramesDiscDp1 Ethernet Port / Emission Priority



#20330 VS.framesTransmittedOk Ethernet Port

#20331 VS.framesReceivedOk Ethernet Port

#20332 VS.octetsTransmittedOk Ethernet Port

#20333 VS.octetsReceivedOk Ethernet Port

#20334 VS.framesTooLong Ethernet Port

#20335 VS.fcsErrors Ethernet Port

#20336 VS.maxRxUtilization Ethernet Port

#20337 VS.avgRxUtilization Ethernet Port

#20338 VS.maxTxUtilization Ethernet Port

#20339 VS.avgTxUtilization Ethernet Port

Counter number

Counter name Granularity

Existing counters allow monitoring of Path Diversity usage.


Ethenernet connection Alarms

• Loss of signal detected on the Ethernet port.

• Auto-negotiation failure detected on the Ethernet port.

• Link offline signaled by the remote end.

• Link failure signaled by the remote end.

• Optical module failure.

• A MAC address cannot be allocated during initial provisioning

• NHR Static Heartbeat failure / recovery.

Existing alarms allow of Path Diversity resources

110761 Multi-Homing on 9370 RNC


110761 SCTP Multi-homing Support on 9370 RNC

FEATURE VALUE

• Zero signalling traffic loss during most classes of IP transport failure (when deployed with Path Diversity and far-end multi-homing).

FEATURE DESCRIPTION

Provides enhanced protection for signalling traffic against IP path failures.

Each 9370 SCTP association has 2 or more paths, each with their own source IP@ (for IuCS, IuPS, Iur)

Far end (MSC/SGSN/DRNC can be single-homed or multi-homed), but latter recommended

Avoids message loss (and higher-layer affects) by sending messages over alternative path during failures.

DEPENDENCIES

• 4PGigE boards

• 110760 IP UTRAN – Path Diversity Support on 9370

• Physically diverse (e2e) transmission paths.

IP Network

9370

SCTPMultiHoming

IP@1

IP@2

MSC/SGSN/DRNC

SCTPMultiHoming

IP@3

IP@4

Normal Operation – SCTP Multi-homing; uses different NHR for each path

IP Network

9370

SCTPMultiHoming

IP@1

IP@2

MSC/SGSN/DRNC

SCTPMultiHoming

IP@3

IP@4

During IP Network failure; no SCTP outage, as SCTP messages are sent on alternate path


Multi-homing – Overview (CN example)

Each association is protected by having two IP addresses (i.e. two paths) to reach the remote SCTP end point.

Offers protection against prolong outage in the IP network.When a transmitted packet is not acknowledged (at the SCTP layer) by the

remote end (within T3 timer), the same packet is retransmitted to the same SCTP end point using the alternate destination IP address (alternate Path).

Engineering IP addresses of each multi-homed end point on different subnets ensures (with physically diverse routing) that packets traverse the network over different routing paths.

IP Network

SrcEp1

SrcEp4

SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

SrcEp2

SrcEP3

SCTP EP3

VR1

Core Network

SCTP EP1

SCTP EP2

M3UA

M3UA

20.1.1.1

20.1.1.211.1.1.4

11.1.1.13

10.1.1.1

10.1.1.2

SCTP EP2

21.1.1.1

SCTP EP1

21.1.1.2

SCTP EP1

SCTP EP1

SCTP EP2

SCTP EP3

SCTP EP2

SCTP EP4

11.1.1.1

11.1.1.2

10.1.1.3

10.1.1.4

Association 1Association 2

Association 3Association 4

NHR A

NHR B

NHR D

NHR C


Multi-homing – Overview (non-fault flow example)

There are four possible combinations of source/destination paths for Association 1: 9370 subnet 10.1.1.1 to CN subnet 20.1.1.19370 subnet 10.1.1.1 to CN subnet 21.1.1.19370 subnet 11.1.1.1 to CN subnet 20.1.1.19370 subnet 11.1.1.1 to CN subnet 21.1.1.1

In a non-fault condition the 9370 will send all UL traffic on the primary path (i.e. one of the 4 paths).

IP Network

SrcEp1

SrcEp4

SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

SrcEp2

SrcEP3

SCTP EP3

VR1

Core Network

SCTP EP1

SCTP EP2

M3UA

M3UA

20.1.1.1

20.1.1.211.1.1.4

11.1.1.13

10.1.1.1

10.1.1.2

SCTP EP2

21.1.1.1

SCTP EP1

21.1.1.2

SCTP EP1

SCTP EP1

SCTP EP2

SCTP EP3

SCTP EP2

SCTP EP4

11.1.1.1

11.1.1.2

10.1.1.3

10.1.1.4

Association 1 (primary path via NHR A)

Association 1 (alternative path, via NHR B)

NHR A

NHR B

NHR D

NHR C


Multi-homing – IP transport failure condition example

During error/fault conditions the 9370 may exercise all four possible paths for UL SDUs.Example Pre-condition: Association 1 UL flows using primary path to 20.1.1.1 via NHR A.When a failure occurs in the IP transport network, SCTP automatically retransmits any

packets for which it did not receive an acknowledgement (existing behaviour). Instead of continuing to re-transmit from same source to same destination, 9370 will now:

Retransmit unack’d packet via alternative path (i.e. via NHR B to 21.1.1.1)If fault persists sufficient long, 21.1.1.1 will become the primary path destination.If fault is transient, 21.1.1.1 will remain the primary, and alternate only used for retransmits.

IP Network

SrcEp1

SrcEp4

SCTP EP4

GigE1

GigE2

NI(a)

M3UA

9370

SrcEp2

SrcEP3

SCTP EP3

VR1

Core Network

SCTP EP1

SCTP EP2

M3UA

M3UA

20.1.1.1

20.1.1.211.1.1.4

11.1.1.13

10.1.1.1

10.1.1.2

SCTP EP2

21.1.1.1

SCTP EP1

21.1.1.2

SCTP EP1

SCTP EP1

SCTP EP2

SCTP EP3

SCTP EP2

SCTP EP4

11.1.1.1

11.1.1.2

10.1.1.3

10.1.1.4

NHR A

NHR B

NHR D

NHR C

Association 1 (alternative path)

Assume this was the pre-fault primary

path.


Converting from single homed Configuration

To configure Local Multi-homing; a secondary IP address (d.e.f.y) is added to an existing source end point:

ss7 sctp/<n> srcEP/<n> srcIpAddr a.b.c.x, d.e.f.yAdding the second local IP address to the endpoint causes the association to be taken

down. There is no service outage, as long as the other associations are kept in service. Hence the multiple associations between the 9370 and remote node should be configured with multi-homing one at the time, and the activation of such configuration should be procedurally coordinated between the two nodes.

The 9370 M3UA deliberately prevents the association from becoming re-established until the remote node is updated to add the new address.

The association will recover (during the INIT sequence) when the second address (known on the 9370 via configuration) is configured on the remote node.This is done as a security measure to avoid masquerade attacks.


SCTP Counters (new in UA08)

Counter number

Counter name Description Screening Granularity

#3005 VS_SctpM3uaKBytes Number of KBytes SCTP protocol sent received to/from the M3UA based on the real time traffic

To / From M3ua SCTP Association

#3006 VS_SctpM3uaMessages Number of messages SCTP protocol sent/received to/from M3UA based on the real time traffic

To / From M3ua SCTP Association

#3007 VS_SctpPeerKBytes Number of KBytes SCTP protocol sent to/received from SCTP remote peer based on the real time traffic.

To / From Peer SCTP Association

#3008 VS_SctpPeerPackets Number of packets SCTP protocol sent to / received from SCTP remote peer based on the real time traffic.

To / From Peer SCTP Association

#3009 VS_SctpDataChunks Number of data chunks SCTP protocol received from or sent to SCTP remote peer and number of duplicated or re-transmitted data chunks SCTP protocol received from or sent to SCTP peer based on the real time traffic. These counters can be used to determine re-transmission rate.

TransmittedDataChunksReTransmittedDataChu

nksReceivedDataChunks

DuplicatedDataChunks

SCTP Association

#3010 VS_SctpOutOfBluePackets

Number of Out Of the Blue packets received by SCTP protocol layer for which the receiver was unable to identify an appropriate association.

none RNC

New in UA08, SCTP counters are available per SCTP association.


M3UA/SCTP Alarms

• 7079 0203 SctpAssociation is down or recovers.

• 7079 0203 SctpAssociation Path is down or recovers.

• 7079 0202 PeerM3uaProcess is down or recovers.

• 7079 0201 PeerM3uaEntity is down or recovers.

• 7079 0200 DestinationSignalingPoint is inaccessible or becomes accessible.

114393 LAG Support on 9370 RNC


LAG Summary

• Intra-card Link Aggregation (LAG) functionality can provide the following key benefits:

• Additional bandwidth, for cases where a single (1 Gbps) GigE link bandwidth is insufficient

• Additional link resiliency for links between the 9370 and NHR


9370 GigE Role Assignment

IuPS, on a separate GigE link

IuR and IuCS share a separate GigE link

Two GE links for Iub LAG

Iub (Port 0, 1)

Single VR for CP and UP

No VLAN required

IuPS/IuCS/IuR (Port 2,3)

Separate VRs for CP and UP

Separate VLANs for CP and UP

Logical View

Physical View

•GE Port •ConnectionType•0 Iub LAG / link0•1 Iub LAG / link1•2 •IuPS UP/CP•3 •IuCS/IuR UP/CP


Intra-card LAG – Overview

Benefits:• Linearly incremental bandwidth: Bandwidth increased by including

additional links under link group.• Link protection: Diverting traffic to remaining links when one link in link

group fails.• Transparent to upper layer protocols: Upper layers unaware of LAG group.• Multiple configuration possibilities: Any combination of 4 links on 4pGigE

card can take part in link group.Feature scope:

• LAG support as per IEEE 802.1ax (previously IEEE 802.3ad) specification.• IEEE 802.3 frame format unchanged; carried transparently.• Supported for IuCS, IuPS, IuR and IuB interfaces.• Integrated with 9370 PDR framework

Considerations:• LAG protocol (as specified in IEEE 802.3ad) must be supported on NHR. • To interwork with routers which have minimal configuration capability, LACP

mode may need to be set to passive and LACP period may have to be set to slow.

• Configuring more than two links in single LAG group will only give added link resiliency and does not contribute to effective throughput beyond 2.5 Gbps (upper limit of backplane interface per card).


Intra-card LAG – Details

• Links grouped together in a LAG must:• Have same link speed and be running in duplex mode

• Be on same GE card.

• Number of links which must be active within LAG group can be configured to declare the LAG group down when the threshold is crossed:

• In event of link failure, number of links in LAG group should be engineered to ensure that remaining links can handle engineered traffic.

• A link can be added under LAG group without disruption of service:

• Distribution function automatically assigns IP Flows over all links in link group.

•Marker/Marker response Protocols facilitates traffic flow migration from one link to another without the need to buffer or re-sequence frames in a traffic flow.

•Some packet loss may be experienced during this procedure.


Load Balancing

D

C

AC

D

C

AC

MAC Client

MAC Client

1

2

3

1

2

3

123L

123L

3

2

3

1

2

1

LACP PDU

MAC Client PDU

LAC

D

C

Agg. ControlDistributor

Collector

LAG supports concept of load balancing without necessity for buffering or re-sequencing at receiving end. Transmits all packets under an IP flow on the same physical link to prevent

mis-sequencing at the receiving end.IP flow is mapped to a single link in LAG group.

Load distribution is done based on the combination of: IP packet src/dst address and src/dst UDP port.


Load Rebalancing

• Load rebalancing triggered when: • LAG Link utilization of at least one LAG Link reaches 70%;• Difference greater than 15% utilization of one LAG Link over

another in the same LAG group;

• For example: Assume Link0 is 80% utilized and Link1 is 60% utilized. In this case, link balancing moves some of the FlowIds from Link0 to Link1.

• LAG balances the utilization of the LAG Links by moving some flows (FlowIds) from the most utilized LAG Link to the least utilized one.


Intra-card LAG – Configuration 3 / Mix configuration (AT&T configuration)

GigE1

GigE2

9370

VR

IP Network

VR

Control Plane

User Plane

CS Core

PS Core

NodeBNodeB

DRNCDRNC

LAG Group 2

IP Network

LAG Group 1

IuCS, IuPS and IuR traffic are carried by individual GigE links and IuB links are grouped under a LAG group.

Has the flexibility of having some of the GigE links part of a LAG group while others are treated as individual links.


LAG configuration Parameters

Parameters Description ValuecollectorMaxDelay Marker protocol timer, for the near-end system

to assume that the destination system has received or discarded all frames transmitted.

Value: 0 - 656 ms; Default: 10

lacpMode LACP mode of the near-end system. Value: passive, active; Default: active

lacpPeriod Timeout period for the near-end system to send and receive LACP frames. Where fast is 1second for sending and 3 seconds for receiving and slow is 30 seconds for sending and 90 seconds for receiving.

Value: fast, slow; Default: fast

minActiveLinks Minimum number of links that must be active for the LAG to remain operational.

Value: 1-4 (for 4pGe); Default: 1

partnerAdminInSystemId Administrative value for the far-end LAG MAC address and Key. Passive mode only.

Default: 00-00-00-00-00-00

partnerAdminKey Administrative value for the far-end LAG MAC address and Key. Passive mode only.

Value: 0 - 65536

partnerAdminSystemPriority Administrative value for the far-end LAG priority. Passive mode only.

Value: 1 – 65536;Default: 32768

applicationFramerName Link to framer component.

statisticsSpooling Enables or disables DCS spooling enabled, disabled; Default: disabled


LAG operational Parameters

Parameters Description ValuefailureCause Cause of the current local end failure experienced by

the LAG.noFailure, noGoodLinks, badLagIdInStartup, badLidInStartup, remoteFailure, minActiveLinksThreshold

actorSystemId MAC address of near-end LAG.

partnerOperSystemId MAC address of fare-end LAG.

runningTime Length of time (in seconds) for which the Lag component has been in the unlocked state

unavailSecs Number of second during which the Lag component has been unlocked and out of service.

failures Number of complete failures, that the Lag component has experienced since being added.

rxFrameOctets Valid user frames, in octets, received

txFrameOctets Valid user frames, in octets, transmitted

rxFramePackets Valid packets received

txFramePackets Valid packets transmitted

rxFrameDiscards Discarded user frames after they were received

txFrameDiscards Discarded user frames during transmission

rxFrameErrors Invalid user frames received

txFrameErrors Invalid user frames prior to their transmission


LAG – Alarms

7011 1500 Lp/<lpNum> Lag <lagIndex>

Indicates that no links are active in the Link Aggregation (LAG) group (i.e. LAG is not capable of carrying any user traffic).

7011 1501 Lp/<lpNum> Lag <lagIndex> Link<linkindex>

Logical link is not active in the Link Aggregation (LAG) group (i.e. link is not capable of carrying any user traffic).

Operational commands monitoring:To determine whether or not the LAG group is active, examine operational state of Lag component:

display lp/n lag/n operationalState

If operational state is enabled, group is active. If operational state is disabled, the group is inactive. In case group is inactive, examine failure cause indicated by the Lag component to determine why group is inactive:

> display lp/n lag/n failureCause

111472 IuFlex Pool support of 24 CNs Nodes


Feature Overview

9370

Iu-Ps/Iu-CS

ATM transport

Iu-Ps

IP transport

SGSNIuPool

SGSN

GGSN

MSC

STM

GigE

IuPool

MSC

MSC

FEATURE VALUE Higher number of CN Nodes in a Iu-

Flex Pool: Improved load sharing across CN

nodes Higher resiliency in case of CN

failure Reduced inter CN node signalling Increased scalability (i.e. additional

CN nodes in a pool).

FEATURE DESCRIPTION

• In UA07, 9370 software supports 24 CN nodes per Iu-Flex domain over ATM for Iu-Ps interface, BUT due to testing restrictions:

•Only 16 CN nodes are supported.

•Over IP only 9 CN nodes are supported.

• Feature lifts UA07 testing restrictions and allows use of 24 CN per Iu-Flex pool for IP (ATM stays the same, at 16).

DEPENDENCIES

N/A

117004 - Support of 3GPP R8

S12 interface on 9370 RNC


PM117004: Feature Scope

• 3G direct tunneling allows IuPS UP traffic to bypass SGSN and go directly from RNC to GGSN.

• Allows offloading SGSN and reduces latency.

• In pre-Rel8, direct tunneling was allowed only towards the GGSN.

• In Rel-8, S12 interface defined to allow direct tunneling between 3G RNC and LTE SGW (Serving GateWay of the LTE network).

• PM117004 introduces support S12 to support direct tunneling between 9370 and SGW.

• Feature scope limited to validating interworking between the 9370 and the SGW via S12 interface.

• Mobility support between 3G and LTE is not in feature scope.


PM117004: Benefit

• Allows operator to offload SGSN UP traffic

• This will decrease the number of required SGSN elements in the network and reduce operator’s Core Network investment.

• Allows operator to leverage LTE core network infrastructure for forwarding 3G data traffic.

• Additional AT&T-related benefit:

• Issue exists with direct tunneling towards GGSN , which is unable to perform legal interception.

• Hence, AT&T deployment would leverage direct tunneling from 9370 to SGW instead of GGSN, as SGW is able to perform legal interception.


PM117004 : REFERENCE ARCHITECTURE

R8 Interfaces used in PM117004:

•S12: Validated via PM117004.

•S4: Required for PM117004 and needed for interconnection between SGSN and S-GW, but PM117004 assumes S4 already validated by CN

E-UTRAN

SGWSGWeNBeNB

MMEMME

PGWPGW

PCRFPCRF

S11

S1-U S5

Gx

SGi

HSS HSS

Rx

S1-MME

S6a

Data ServicesData Services

(e.g., VPN, FTP)(e.g., VPN, FTP)

ApplicationApplication

FunctionFunction

UTRAN

NBNBNB RNCRNCRNC

SGSNRel8

SGSNSGSNRelRel88

S3

Iu-ps

S10

Iub

Gror S6d

S4S12

Control plane

User plane

Anchor of the

IP session

Anchor for

3GPP mobility

Not part of PM117004.


S4 (SGSN-SGW): Provides control and mobility support between GPRS Core and Anchor function of Serving GW. If Direct Tunnel not established, provides the user plane tunneling.

PM117004 : REFERENCE ARCHITECTURE S3 (SGSN-MME): Enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or active state.

E-UTRAN

SGWSGWeNBeNB

MMEMME

PGWPGW

PCRFPCRF

S11

S1-U S5

Gx

SGi

HSS HSS

Rx

S1-MME

S6a

Data ServicesData Services

(e.g., VPN, FTP)(e.g., VPN, FTP)

ApplicationApplication

FunctionFunction

UTRAN

NBNBNB RNCRNCRNC

SGSNRel8

SGSNSGSNRelRel88

S3

Iu-ps

S10

Iub

Gror S6d

S4S12

Control plane

User plane

Anchor of the

IP session

Anchor for

3GPP mobility

S12 (RNC-SWG): Provides user plane tunneling when Direct Tunnel is established. Based on the Iu-u/Gn-u reference point using the GTP-U protocol.


PM117004 : S12 Interface

S12 protocol stack similar to IuPS (IP-based transport)


www.alcatel-lucent.com

9370_ip_transport_(june_2012)_

Documents

perform legal

rights reserved

local diagnostic

remote diagnostic

kbytes sctp

egress path

bidirectional

user plane