Hi, really interesting.
Does your DECT Network belong to a separate high priority dedicated VLAN (let's say you defined a IP-DECT dedicated VLAN) traversing all involved Switches? yep, I see, it does (VLAN 30).
That seems to be an essential requirement (a mandatory one) for similar IP DECT deployments (as example, the one offered by Siemens - now Unify - with its HiPath Cordless IP V1 system) and there is also a quite common recommandation about the maximum supported number of cascaded Switches between the BSIP Sync Master and BSIP Sync Salves (so it's important where the Sync Master BSIP is located/defined); also Layer 3 Routing is not supported between the DECT Server (represented by a BSIP Base Station operating in IWU mode or by a bare metal Server which operates as Server IWU) and BSIP Base Stations operating in BSIP only mode...but this, I think, you know yet.
How is your Synchronization Topology (where is the BSIP Sync Master with respect to the BSIP Sync Slaves)?
How is your Network Topology in terms of Trunk Uplinks between the Switches?
Do all your involved Switches manage high traffic situations?
As example the Unify HiPath Cordless IP V1 (which is basically an Ikon GmbH based IP-DECT system) reports a maximum of 700 ns for Jitter (Variation of Delay), stating that higher values will definitely lead to re-synchronizations (so IP-DECT calls go KO).
Regarding the LAN Synchronization (IEEE 1588 PTP) I've to admit that the Siemens solution uses a method that was developed using the IEEE 1588 as a base: as someone at Siemens told me four years ago, to overcome the issue represented by Low End non IEEE 1588 compliant Switches or by High End IEEE 1588 compliant Switches that show high Jitter values even with low traffic situations, they developed a method that let the "...Master BS to generate UDP messages with time stamps and send them to the Slave BS(s). The Slave BS(s) are then able to read the time stamps and so to deduct the flying time needed between Slave and Master. If this is successful the different time bases in the different DECT IP Base stations are kept in sync...during the development was recognized that Jitter variations are most critical, if the Jitter is constant the developed methodology can adapt this Jitter, but if the Jitter varies very much, this methodology is not able to adapt the Jitter to a fix value. The LAN synchronization will not work in this case."
Indeed LAN Synchronization, in contrast to the DECT Synchornization (Over the Air), requires a PSR (Project Specific Release) approved by Siemens/Unify.
Don't know much about Spectralink IP Dect solution and its requirements (apart of what is reported in their Spectralink DECT/IP-DECT Server 400/6500/2500/8000 Synchronization and Deployment Guide here) so I can't judge if their requirements are too strict or not (at some point they state that "The total forwarding jitter added by switches on any path through the deployment network should be less than one microsecond and preferably less than 100 nanoseconds." but I haven't any means to understand if this requirment is too strict or not even with HP ProCurve Switches)...but, hey, first:
- Do HP ProCurve Switches support IEEE 1588 Version 2 (PTPv2) or IEEE 802.1AS? <- I found NO reference for that (on the contrary the HPE FlexNetwork family seems to support it) in any QuickSpecs or Configuration Manuals.
- What are the HP ProVision 6th Generation ASICs specs (related to HPE 5400R zl2) regarding the delay time (in nano-seconds or fraction of micro-seconds) added to process/manage PTP traffic? <- really don't know but, personally, I expect at least that an High End Switch to perform significantly better than a Low End one!
Edit: consider, I'm reading it now on a IEEE 802.3AS six years old presentation, that one of the 802.3AS golas was to keep the time at any two LAN-attached stations accurate to within +/- 500ns (assuming 7 newtork hops) and that 802.3AS goals were not to:
- Improve the latency of media packets
- Improve the delivery jitter of media packets
- Improve latency or delivery jitter of 802.1AS packets
- Provide clock which all media must be synchronized to
- Solve time synchronization over 802.3 only (or .11 only)
Also, be careful when looking for IEEE 1588 PTP support on various HPE Switches QuickSpecs...I found now that HPE reports it incorrectly as RFC 1855 PTP (gosh!) so when doing a research specifically for 1588 I initially found nothing even if the Switch appears to support it (see here for HPE FlexNetwork 5900 Switch Series QuickSpecs, just as example).
I'm not an HPE Employee
@svhelden wrote:In our topology, we have few cascaded switches, but it's not more than 5 switches between any base stations. All switches are interconnected with 1 G links (copper or fiber), and all involved ports have zero failures/drops.
I've read that only the Store and Forward Latency of an Ethernet Switch for the maximum size Ethernet frame (1500 bytes) at 100 Mbps is about 120 μs...for comparison...the minimum size frame (64 bytes) at Gigabit speeds has a latency of just 0.5 μs (but 0.5 μs are still 500 ns, aren't?)...this without considering Switch Fabric Latency, Wireline Latency (really trascurable in LAN) and Queueing Latency (sensible to Network load).
So when I re-read the Spectralink 100 ns critical threshold...well...I start thinking their one is very strict (is it really possible to stay below the 100 ns threshold within the same Switch?).
@svhelden wrote:Spectralink specifically say that they do NOT support such thing as 'PTP-compliant switches' ;)
Yep, also the Siemens HiPath Cordless IP V1's Product Manager (at time, so 4 years ago) stated something very similar...they didn't rely on IEEE 1588 Switch capabilities to permit the LAN Synchronization...but actual documentation seems to say the contrary (see below).
The recommandation about the maximum supported number of cascaded Switches admitted between the BSIP Sync Master and any BSIP Sync Salve is only 3 for the HiPath Cordless IP solution (your is higher but you have Spectralink...on the other hand it's also clear that you still have issue within the same Switch and not only between them...but...it's important to understand where is located - in the network topology - the BSIP Sync Master with respect to all BSIP Sync Slaves <- Star Synchronization Topology only).
And just a configuration example:
As you see the example above starts from a very simplified topology (basically no cascaded Switches).
@svhelden wrote:Could it be related to VoIP traffic that shares the same priority?
Probably: Siemens recommends to separate VoIP VLAN from DECT Network VLAN and give to this one the highest priority (see above).
Don't forget how much high traffic situations - within a Switch or between them - can impact the Jitter value!
Note that Siemens placed all the BSIP(s) Base Stations (IWU too) within the control of just a single Switch! <-- that's a simply too ideal scenario in my opinion.
Real world cases, like your one, are a little bit more complex (or a little bit less simple).
I'm not an HPE Employee
@Sorry Vince I induced you in a error when I wrote:
@parnassus wrote:I've read that only the Store and Forward Latency of an Ethernet Switch for the maximum size Ethernet frame (1500 bytes) at 100 Mbps is about 120 μs...for comparison...the minimum size frame (64 bytes) at Gigabit speeds has a latency of just 0.5 μs (but 0.5 μs are still 500 ns, aren't?)...this without considering Switch Fabric Latency, Wireline Latency (really trascurable in LAN) and Queueing Latency (sensible to Network load).
So when I re-read the Spectralink 100 ns critical threshold...well...I start thinking their one is very strict (is it really possible to stay below the 100 ns threshold within the same Switch?).
because I created a non-existent relationship between the overall traffic forwarding latency of a Switch's port and the Jitter its traffic can suffer of.
Forwarding Latency, on its own, has nothing to do with the Jitter (Variation of Delay)...overall traffic load can do. So it's perfectly possible to have a Switch capable of an average forwarding time of less than 3 μs (3000 ns) and still having its Jitter in the region of hundreds nano-seconds.
The point here is to understand how much a specific system (Spectralink DECT-IP) can tolerate Jitter for PTP traffic it generates...an average range of +/- 100 ns is very low, +/- 700 ns is seven times more.
I'm not an HPE Employee
@svhelden wrote:We tested with multiple stations as master, without notable difference.
Don't you see any difference if you assign the Sync Master role to a Base Station connected to the same Switch that connects most of the others (Sync Slave) Base Stations?
I'm not an HPE Employee
@svhelden wrote:One more note, I noticed that older HP switches had an option "ip igmp high-priority-forward", which seems to be gone from newer models. Is there any replacement for this command, or is the functionality gone completely?
Strange.
On latest HPE ArubaOS-Switch Software Multicast and Routing Guide for K/KA/KB.16.01 (May 2016) there is a clear reference (sheet 30) about IGMP traffic normal/high-priority forwarding feature with or without IP addressing configured on VLAN but then, looking at the command ip igmp options, there isn't (sheet 39)!
Considering your reported QoS settings:
qos dscp-map cs5 priority 7 name "Lync-40" qos dscp-map ef name "Lync-46" qos type-of-service diff-services vlan 30 name "DECT" ip igmp
I'm curious enough to ask you to show yours QoS DSCP mappings (with show qos vlan-priority and show qos dscp-map)...could you? I never stop learning.
I'm not an HPE Employee
I think you're not alone...but...are you asking that...with PTP related issues/restrictions [*] in mind or, let's say, totally in general about the whole technology (maybe compared to "pure DECT" or to "pure VoIP over WLAN")?
Just curious.
[*] we should keep in mind that synchronization between DECT IP Base Stations (which is the prerequisite for seamless handover withing the same DECT IP cluster) - normally on small deployments - happens "Over the Air" (also called "DECT based synchronization") [**] and this is more true if there aren't design limitations on the number of installable base stations (to grant the right overlapping) and about their placement on the entire covered site (to ensure the requested overlapping).
[**] for synchronization "Over the Air" (by means of DECT - so on range of 1.8/1.9 GHz - radio signals), the DECT IP Base Stations that synchronize each others must be able to exchange their management information (Beacons) flawlessly so those base stations must be located in areas where their radio cells overlap respecting the requested RSSI (Received Signal Strength Indication) not only between them and moving DECT mobile terminals but also between them too.
I'm not an HPE Employee