search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.78k stars 2.54k forks source link

Interface Type Additions for LTE Standards #2866

Closed tyler-8 closed 5 years ago

tyler-8 commented 5 years ago

Environment

Proposed Functionality

There are multiple LTE standards (similar to WiFi/802.11) so it would also be beneficial to track the particular standard of the interface. These are likely the most common ones out there to start:

IFACE_FF_LTE = 2800
IFACE_FF_LTEA = 2810
IFACE_FF_LTEAP = 2820

[IFACE_FF_LTE, 'LTE'],
[IFACE_FF_LTEA, 'LTE Advanced'],
[IFACE_FF_LTEAP, 'LTE AdvancedPro']

Depending on the discussion, I could see these being grouped under the existing Wireless heading or potentially their own category.

Use Case

LTE is a common method of connectivity for sites or as a backup, or OOBM, even in a datacenter. LTE routers, such as Cisco's 800 or 1100 series, Cradlepoint's IBR platform, etc., have a "Cellular" interface that wirelessly connects to the provider network.

LTE is an IP-based architecture, with interfaces receiving IP addresses from the provider so I think their form factor fits the previous interface type discussions I've read in past issues.

Database Changes

None (representations are handled in code rather than DB structure).

External Dependencies

NA.

DanSheps commented 5 years ago

I want to point out what was stated in #1865:

The litmus test for whether something counts as a network interface is generally "can you put an IP address on it, and is it still in common use?" Additionally, "form factor" is a misnomer in this instance (I'd actually like to rename it a some point) as it describes a physical interface type like 1000BASE-TX or SFP+. So we wouldn't add RJ-45, for example, because several Ethernet standards employ it. And I don't know of any DB25/DE9 interfaces which support IP routing still in common use.

I think a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here.

sdktr commented 5 years ago

I think a generic "Cellular" interface (or how Cisco does it: "Dialer", which also covers PPPoE connections) would be the better method here.

I agree, just like a 'generic' xDSL interface (not in netbox today) instead of all it's flavors.

tyler-8 commented 5 years ago

@DanSheps I think the LTE case matches those statements quite well (an IP address and description of the physical interface type). This is a description of the physical antenna's capabilities/interface type (LTE vs LTE-A, like 1000BASE-TX and SFP+) rather than the signal.

The bottom of this article lists the different cellular network standards out there, so we could go the full way and define most of the modern ones in a "Cellular" section (which I'm happy to do). I went with the 'primary' LTE flavors, rather than the intricacies of the 3GPP specifications as I think it's a happy medium between too generic and too specific.

"Cellular" is just the interface name in Cisco, it's not a description of the physical component. The hardware component is seen in this Cisco output:

#sh int cell 0/2/0
Cellular0/2/0 is up, line protocol is up
  Hardware is LTE Advanced pluggable - Europe/North America Multimode LTE/DC-HSPA+/HSPA+/HSPA
  Internet address is XXX.XXX.XXX.XXX/32

And LTE is a standard (technically 3GPP) with similar "versioning" as 802.11, which is captured in Netbox already, and just as important (LTE vs LTE-A vs LTE-AP) and IMO, sufficiently different from other wireless or dial based protocols.

jeremystretch commented 5 years ago

I'm happy to add these, but we need to lock down the different specifications that should be defined. I'm not very familiar with cellular service, but providers are not unaccustomed to making up their own specs (looking at you, AT&T). Is there a significant benefit to defining more than just "LTE" for the immediate future?

tyler-8 commented 5 years ago

The 3 variations in my OP cover the existing LTE implementations fairly well I think. Those are not carrier-specific names, they are from the 3GPP (basically a standards body for GSM, CDMA, and LTE that is comprised of telecommunications groups around the world).

The term "3GPP specification" covers all GSM (including GPRS and EDGE), W-CDMA (including HSPA) and LTE (including LTE-Advanced and LTE-Advanced Pro) specifications, and the emerging 5G specifications.

The differences between those LTE types is akin to the variations of the 802.11 standard. "LTE" alone would be better than current state, but I can certainly see value in having the subtypes defined as well.

DanSheps commented 5 years ago

I think what @jeremystretch is asking, is do we really need to get granular with LTE itself? I don't think so.

The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth. I see this as more of a difference between 20/40/80 channel widths in 802.11 and I don't think it necessitates a different standard being added.

HOWEVER, I would see value in adding GSM and W-CDMA, with the LTE so you would have three choices (GSM, CDMA, LTE), because those are significant differences in the technology and not everything is compatible there whereas with LTE Advanced it is still LTE (Just like 802.11n with 20Mhz is still fundamentally the same as 802.11n with 40Mhz channel width)

tyler-8 commented 5 years ago

do we really need to get granular with LTE itself?

If you had a large fleet of LTE-* capable devices all varying between LTE/LTE-A/LTE-AP you might feel differently. It would be useful to know which devices support which standard. Sometimes this can be sufficiently captured based on the device hardware model - but that isn't always the case.

The main difference I see with LTE, LTE Advanced, and LTE Advanced Pro is the channel bandwidth.

It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands).

Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out.

As for GSM and CDMA, those could be useful additions as well. I suspect their use will decline in the networking space, if it hasn't already, CDMA in particular. Both of those protocols don't see much/any evolution of the specification so they certainly won't need any subgroups to define.

Proposed schema:

IFACE_FF_CDMA = 2800
IFACE_FF_GSM = 2810
IFACE_FF_LTE = 2820
IFACE_FF_LTEA = 2830
IFACE_FF_LTEAP = 2840

[IFACE_FF_CDMA, 'CDMA'],
[IFACE_FF_GSM, 'GSM'],
[IFACE_FF_LTE, 'LTE'],
[IFACE_FF_LTEA, 'LTE Advanced'],
[IFACE_FF_LTEAP, 'LTE AdvancedPro']
DanSheps commented 5 years ago

It's a bit more than that. The changes in bandwidth are due to the improvements to 'carrier aggregation' which allows a device to connect to multiple bands at once, thereby achieving (theoretical) significantly higher data rates. In LTE, a device could only connect to one band at a time, LTE-A took this to 5, and LTE-AP took this to 32 (and introduced new bands).

Also MIMO, lower latency, and a few other things. In my opinion the differences between the 3 are significant enough to warrant them being spelled out.

These are all similar to N, and we don't differentiate between N and "N Advanced". I would say if there is a need it could be added, but for now just stick with LTE and maybe leave a "gap". I personally don't want an interface list a mile long and adding all of these corner case specifications is going to get:

  1. Tedious to implement
  2. Ridiculously long

If we are doing LTE Advanced, what is to stop someone from requesting 3G, HSPA, etc?

The goal with interfaces is to model the "physical" interface in my understanding, and the "physical" interface here is LTE, the change with LTE/LTE-A/LTE-A-Pro (Sidebar, lets be real, this is just to sell more phones, because the average consumer needs to have the latest and greatest tech and adding "advanced" and "pro" is going to get people jumping. No one would even give it a second look if they said "LTE is now going to support carrier aggregation and larger channel widths" without the "Advanced" or "Advanced Pro" badge) is just expanding the capabilities of those interfaces by bolting on new tech (channel bonding).

tyler-8 commented 5 years ago

All I can say is I think the differences are not trivial and that the differentiation would have value for me. In any case, having LTE alone as an option would be preferable to current state.

# Cellular
IFACE_FF_CDMA = 2800
IFACE_FF_GSM = 2810
IFACE_FF_LTE = 2820

[IFACE_FF_CDMA, 'CDMA'],
[IFACE_FF_GSM, 'GSM'],
[IFACE_FF_LTE, 'LTE'],
jeremystretch commented 5 years ago

I'm going to add GSM, CDMA, and LTE for now. We'll see if the issue of regular/advanced/advanced pro differentiation comes up again once people start using the new LTE option.