Upload
azharz4u
View
49
Download
3
Tags:
Embed Size (px)
DESCRIPTION
ip
Citation preview
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)
All Rights Reserved © Alcatel-Lucent 20094 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 20095 | May 2011
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
All Rights Reserved © Alcatel-Lucent 20096 | May 2011
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
All Rights Reserved © Alcatel-Lucent 20097 | May 2011
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
All Rights Reserved © Alcatel-Lucent 20098 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 20099 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200910 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200911 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200912 | May 2011
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 @
All Rights Reserved © Alcatel-Lucent 200914 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200915 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200916 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200917 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200919 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200920 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200921 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200922 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200923 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200924 | May 2011
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
#20321 VS.txFramesDiscDp2 Ethernet Port / Emission Priority
#20322 VS.txFramesDiscDp3 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.
All Rights Reserved © Alcatel-Lucent 200925 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200927 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200928 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200929 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200930 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200931 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200932 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200933 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200935 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200936 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200937 | May 2011
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).
All Rights Reserved © Alcatel-Lucent 200938 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200939 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200940 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200941 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200942 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200943 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200944 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200946 | May 2011
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
All Rights Reserved © Alcatel-Lucent 200948 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200949 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200950 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200951 | May 2011
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.
All Rights Reserved © Alcatel-Lucent 200952 | May 2011
PM117004 : S12 Interface
S12 protocol stack similar to IuPS (IP-based transport)
All Rights Reserved © Alcatel-Lucent 200953 | May 2011
www.alcatel-lucent.com