Kitz Forum
Broadband Related => Broadband Technology => Topic started by: Weaver on May 05, 2018, 01:43:16 AM
-
Until some months back I used to see entries in the BRAS column of AA’s clueless.aa.net control server which were names of the relevant BRAS that each of my three links was ultimately connected to. Then it changed, the names are now gone and all three show 213.1.180.152.
Apart from the obvious, what does that IPv4 address mean? (https://apps.db.ripe.net/db-web-ui/#/query?bflag&searchtext=213.1.180.152&source=RIPE#resultsSection https://myip.ms/view/ip_addresses/3573658624/213.1.180.0_213.1.180.255)
I think it is a box in Edinburgh. If memory serves there used to be some box in Falkirk that was mentioned at one time, perhaps that was in the 20CN days.
If that box is on the public internet then I find that surprising. Perhaps it is so heavily firewalled off that they have no worries.
Is there a chance that that IP address is used in (PPP over) L2TP over UDP over IPv4 then, to the ISP? So the ISP needs IPv4 at their end of the tunnel.
And I don't see it as a hop because the PPP tunnel I live in goes straight (ish) through it?
-
Interesting, well I guess there's a good reason why it's changed.
For comparison, mine are showing up on control.aa.net.uk for the two bonded FTTC lines as:
- LTS2.VDSL.THW.TTNEW
- LTS2.VDSL.HEX.TTNEW
Which should both be in London, two different datacenters, Telehouse West and Harbour Exchange.
-
Ixel, those are names, textual then?
-
Don't need firewalls. Can just not advertise those prefixes to public Internet, only to kit that needs to connect to it.
IP addresses are required to transport L2TP if there's no ATM network to carry the stuff or other encapsulation. Carried over UDP port 1701.
-
I'm on 21CN ADSL2+ now, so as I understand it that means no more ATM between DSLAM / MSAN (now) and BRAS so ethernet and possibly VLANs in it? And what, L2TP over UDP over say IPv4 over ethernet over something optical - just guessing - from DSLAM / MSAN to 21CN BRAS ?
Is that right? It's not just the BRAS-to-ISP side that uses L2TP perhaps then?
I've never managed to find out too much about the MSAN to BRAS path. Burakkucat and I were talking about it a good while back and I collected a list of every mention I could find, every scrap of info about the protocol stack along that stretch.
These are the notes I put together back then :
Exchange backhaul protocols BT 21CN MSAN
* BT 21CN: SIN466 says Ethernet, no mention of ATM at all.
* BT 21CN: SAMKnows states Ethernet replaced ATM
https://www.samknows.com/broadband/exchanges/21cn_overview
But perhaps SAMKnows doesn't know :-)
* BT 21CN So does this : http://blog.farnz.org.uk/2010/02/on-pppoa-pppoe-atm-and-adsl.html
Q: Is WBC 21CN? - If so, SIN 472 v2, sec 3.7 says “WBC uses ATM over DSL for the link between the end user and the MSAN but Ethernet between the MSAN and the BRAS.”
Q: Is 21CN TR-101 a description of BT 21CN ?
This page hints that it is, not v explicit - https://support.zen.co.uk/kb/Knowledgebase/Zen-ADSL-Broadband-Products-Line-Data
Also, this post claims it is - http://forums.thinkbroadband.com/zen/4075096od-tr101.html?fpart=all&vc=1
* If that's so, TR-101 (2006) talks unambiguously about the total replacement of ATM with Ethernet, and hallelujah that spec has explicit protocol stacks! Yay!
* Weak support: 21CN - the following doc makes no mention of ATM for 21CN, only ethernet
http://www.edinburgh.bcs.org/events/2007-08/080109.ppt
Vvery weak hint: VDSL2 :- Paper by Eriksson and Odenhammar: Ericsson Review no 1 (2006) - "VDSL2", p. 38 - “The elimination of ATM in the first mile means the access architecture can be simplified into an end-to-end Ethernet access architecture that uses virtual local area networks (VLAN) as the service-delivery mechanism across the entire access network.” - does this apply to 21CN?
-- TR-101 refs --
2006:
a. Sec 2 "migration process from an ATM based aggregation network to an Ethernet based aggregation network."
b. sec 2.3 (p 21);
-
Ixel, those are names, textual then?
Indeed, that's how it appears on the main page at control.aa.net.uk for me. I can see the IP address of either if I want to however.
-
On 21CN an MSE in an exchange is usually your BRAS. Other concentrators / LACS may be used on the way to the ISP LNS but that's likely what you're seeing.
21CN uses an MPLS network. Hops are hidden by L2TP and indeed PPP. Your data doesn't have any TTL drop on its way to the ISP as there are no points where the IP traffic inside your PPP session is used or decapsulated.
Your very weak hint paper mentions the access network. FTTC does indeed use VLANs, as does FTTP. 21CN does not in the same way. It uses L2TP riding over IP to segment traffic, with individual PPP sessions inside the L2TP tunnels. VLANs are used to split customers, backhaul uses VLANs but these are not expressed to customers and aren't actually required, but make management, QoS etc easier as these backhauls carry a variety of traffic with varying priorities and service levels, not just residential broadband. You'll have seen mention of SVLANs.
FTTC delivers subscribers to CPs via nested VLANs. SVLANs / Service VLANs to individual CPs inside which are CVLANs, Customer VLANs.
-
On 21CN an MSE in an exchange is usually your BRAS. Other concentrators / LACS may be used on the way to the ISP LNS but that's likely what you're seeing.
21CN uses an MPLS network. Hops are hidden by L2TP and indeed PPP. Your data doesn't have any TTL drop on its way to the ISP as there are no points where the IP traffic inside your PPP session is used or decapsulated.
Your very weak hint paper mentions the access network. FTTC does indeed use VLANs, as does FTTP. 21CN does not in the same way. It uses L2TP riding over IP to segment traffic, with individual PPP sessions inside the L2TP tunnels. VLANs are used to split customers, backhaul uses VLANs but these are not expressed to customers and aren't actually required, but make management, QoS etc easier as these backhauls carry a variety of traffic with varying priorities and service levels, not just residential broadband. You'll have seen mention of SVLANs.
FTTC delivers subscribers to CPs via nested VLANs. SVLANs / Service VLANs to individual CPs inside which are CVLANs, Customer VLANs.
So to get this straight, I'm really not sure at all about the protocol stacks here so I'm going to make a wild guess. I'd appreciate correcting so I fully know the whole process
Traffic from ADSL2+ customers will leave the modem as IP over PPP over PPPoE over Ethernet over AAL5 over ATM over ADSL2+, it will go through the MDF,HDF to the CMSAN, CMSAN removes ADSL2+, ATM and AAL5 and frames the Ethernet frame in GFP and SDH and it is sent to the FMSAN and then to the Tier 1 MSAN which performs WDM and it is received by the Metro EEA which demultiplexes? and adds MPLS label and it goes to the bRAS which terminates the PPPoE session and places the PPP session in the L2TP tunnel over UDP over IP over MPLS then it goes to the AP port on the BEA, then through the MSIL onto the core network using MPLS to route to the core node next to the ISP and the ISP edge router functions as the PPP terminator which removes PPP, L2TP, UDP and the IP packet travels raw over the ISP network
Traffic from FTTC customers will leave the modem as IP over PPP over PPPoE over Ethernet?PTM? over VDSL2, the DSLAM in the cabinet removes VDSL2 and encapsulates the Ethernet in GFP, SDH and it continues through the E side ducts, the OCR, the OLT and the L2 switch and then to the F.MSAN? and then to the Tier 1 MSAN and so on as above
Traffic from legacy 20C customers will leave the modem as IP over PPP over PPPoA over ATM over ADSL and go to the DSLAM in the exchange not sure whether it keeps ADSL on or strips it off and replaces with another PHY layer, but it goes through the virtual path and the ATM MSiP backhaul to the bRAS which terminates the PPPoA, strips off the ADSL and ATM layer and encapsulates the IP packet in L2TP over UDP over IP over MPLS over Ethernet and travels to the EEA it is connected to which aggregates it with other customers to travel over the MSIL pipe to the ISP LNS which terminates the L2TP tunnel
Of course. There are many inaccuracies here and I would love for them to be corrected so I get a better understanding. A further question I'd like to ask is where Virgin comes into the BTw network and also how the BTw network is connected to Tier 1 ISPs like Deutsche Telekom
-
Superb piece of work, fantastic, thank you. Regarding FTTC in the CPE modem, I would think it has to be IP over PPP over PPPoE over Ethernet over PTM over VDSL2, as you say.
I don’t think that it is correct about PPPoA vs PPPoEoA being linked with 20CN vs 21CN is it? Are the two not just independent? 21CN ADSL exchanges will support two types of CPE which will speak either PPPoEoA over ADSL or PPPoA over ADSL.
To be completely accurate when talking about ADSL we would have to say “PPPoE over Ethernet over RFC2684 over AAL5 over ATM”, rather than just “PPPoE over Ethernet over AAL5 over ATM” for the case of PPPoEoA, and also similarly add “RFC2684 over (AAL5)” in the case of PPPoA.
-
Will come back to this later but nowhere is PPPoE over Ethernet used. PPPoE doesn't need another Ethernet encapsulation it already has one, the E part in PPPoE. Also 21CN uses PPPoA, the ATM is stripped at the MSAN.
The 21CN MSANs for most subscribers feed into an MSE, Multi Service Edge, which terminates the PPP session then re-encapsulates. None of this kit does WDM, it is not transmission equipment.
The cabinet MSANs do not do SDH. Ethernet only. GTP is not used here at all, just Ethernet, with 802.1ad.
The transmission equipment that has to worry about SDH is separate kit. Wholesale buy circuits from Openreach, Openreach's problem how to transport them.
-
Traffic from FTTC customers will leave the modem as IP over PPP over PPPoE over Ethernet?PTM? over VDSL2
Not necessarily.
Talktalk use IPoE instead of PPPoE
Sky do similar with DHCP Option 61
-
May come back to this again but multiple MSANs aren't used as a general rule. These are for terminating broadband lines and those are already terminated by the MSAN. FTTC has no MSAN after the cabinet, and there's no mention of CableLinks. L2S and OLT are actually the same thing in at least some cases now. A big converged edge box, probably a Huawei 5600T in at least some cases, with some line card slots populated with OLT cards and others with Ethernet ports of 1G or 10G variety for L2S duty.
Having DSLAMs retain xDSL as a physical layer for presentation deeper into the network isn't going to happen. DSL is there to provide transport over the copper telephone network.
Reading a subsequent post I see another mention of PPPoE being a separate layer to PPP or Ethernet. It's not - it is PPP over Ethernet. Running a PPP session inside another PPP session or encapsulating Ethernet frames inside Ethernet frames is crazy. There's enough overhead there already without adding more.
Suggest reviewing the 'basics' of how this stuff works and the protocols are layered. Without that I could recite pretty much the components and where they fit in but it wouldn't make sense.
-
Carl, I ought to confess - it’s a matter of terminology. You and I are in agreement, in fact. I was talking about individual headers, so counting PPPoE as three things not one, because of the individual headers. You are of course quite correct that PPPoE implies PPP and Ethernet that’s what it’s for, to carry the one over the other ultimately. And I agree about ATM being stripped at the MSAN in 21CN, I was arguing for this in an earlier post. I think I also confused you because in that recent post I was talking about the link between CPE and MSAN, not further upstream, and that was not helpful. I didn’t mean to imply that xdsl was going further into the network. Sorry for the confusion. I was uncertain about the stuff further upstream than the MSAN and was trying to work it out based on a lot of vague articles I’ve read. But I have very good, detailed references for the variety on first-mile protocol stacks in use.
-
Hey guys, thanks for this helpful information. With regards to PPPoEoE, I thought that's just PPPoE in an Ethernet frame, the PPPoE encapsulation containing the PPP payload, length, session ID, code, type and VER, which in itself is the Ethernet payload. The below image I just found should help
-
Please see https://tools.ietf.org/html/rfc2516
PPPoE is PPP transported over Ethernet. I guess they included redundant information in the diagram as an attempt at extra clarity.
Weaver: I was referring back to an earlier post rather than answering yours, Sir, please excuse my lack of clarity.
-
Terry, 20CN with PPPoEoA wasn’t quite as pictured because ATM used to extend further into the network according to our own kitz who has a full 20CN diagram. And PPPoA is far more common that PPPoEoA in the UK for ADSL users, and that of course is different.
That seems to be a plausible 21CN picture for all I know. So we are told in this thread by those who know that PPPoE and Ethernet no longer extend further upstream beyond the first mile, beyond the MSAN aka Posh DSLAM. I had just assumed that PPPoE extends nowadays all the way much further upstream to the BRAS, not having any clue, but explicit description of this kind of situation that I have read, including one from Germany, were not saying which generation of systems they referred to, and were just outdated it seems. There’s no reason to do such a thing. And Kitz told me that PPP gets terminated and possibly fiddled with initially, and a new PPP connection goes upstream from the BRAS all the way to the ISP, rather than one single unbroken PPP connection all the way from the user’s router to the ISP.
They have left out the RFC 2684 header. That is a bit of useless glue between Ethernet (which is below PPPoEoA) and AAL5 below. It is actually a set of several different alternative headers and protocols, two lots according to the different upper layer protocols above AAL5 and for each a set of further options that set the stupidity-level of how much extra bloat you want. There is only one sane choice given a free choice: the right answer has the least bloat and that’s what you always use unless the DSLAM you have won’t support it. RFC 2684 is a multiprotocol labelling thing, more possibly pointless bloat which contributes to a grand total of 32 bytes of total bloat in a typical PPPoEoA ADSL protocol stack. The Wikipedia article on PPPoE has a section on PPPoEoA header bloat and compares it with PPPoA (sanity). I hope that article might be useful, and I do hope it is accurate because I wrote the PPPoEoA section.
In any case the whole multiprotocol indication thing is completely wildly duplicated over and over again. There are protocol fields in Ethernet in the ‘ethertype’, PPP also handles protocol mux / demux very well rather more extensively, IP has the version field anyway which shows whether something is IPv4 or IPv6 (has anyone ever actually used that ? Try getting it wrong in the sense of putting correctly formatted packets of the wrong protocol in the wrong place? ) and there is something in the RFC2684 header too. Only ethertype and PPP are any use. RFC 1483 is the same thing, replaced by an update called RFC 2684 iirc so some modems mention ‘RFC 1483’ settings instead but there’s no difference at all.
Anyway, to be fully accurate you would say which one of the RFC 2684 variants is in use. To make things worse, in PPPoEoA the ‘ethernet’ header actually comes in one of two versions, in theory, a 14 byte one or an 18 byte one if you want to add yet more bloat and slowness. I have never tried experimenting so I don’t know if say BT ADSL 21CN or 20CN DSLAMs when using PPPoEoA can handle both types of Ethernet header. So the whole grad title would be ‘+ Ethernet (FCS|noFCS) + RFC 2684 ‘bridged’ LLC + AAL5 + ATM + ADSL’. And the ‘bridged’ means it is the set of RFC 2684 variants that is used for carrying Ethernet and so in this case where it is (always) Ethernet, the set of variants will always be the set called ‘bridged’. The ‘LLC’ option selects the specific RFC2684 header flavour within the allowed alternatives and with that we know exactly which section within the RFC2684 doc we are looking at and so exactly what form the header has.
So for ATM in ADSL this header in one sense cannot be forgotten, because this is where various modem settings live : ‘VC-MUX’ vs ‘LLC’ being one two-way choice and ‘FCS’ being a Boolean, on / off or present/absent. However in another sense you may well not need to bother about the RFC 2684 variants, because the modem’s defaults might well just be the sane choice (although I always check) anyway: Provided the DSLAM supports it, you never need to make use of the different possibilities, and can stick to one sane answer. The right answers for BT ADSL are always :- for PPPoA: “VC-MUX”; and for PPPoEoA: “LLC + no-FCS”. Never ever use anything else.
How did this post grow into such an uncontrolled monster, uncalled for and off-topic probably? What a fool I am.
-
Could we at some point write consensus summaries for all the cases then, as I simply don’t have all of this vital stuff anywhere.
I didn’t have the stuff for 21CN upstream of the MSAN. I don’t understand anything much regarding the FTTC picture but I do have G.993.2 to read at least yet that is not remotely enough, I need all the stuff above it and the stuff upstream from the FTTC cab and further.
-
Right there are a few things I'd like to address actually. The main burning question for me right now is why the BTw converged network diagram features a 21cn bRAS, an IEA AND and MSPE, like, why are there so many bRASs on that path? shouldn't there just be a single one, what's the purpose of the IEA and 21cn bRAS? Isn't the MSPE the LAC here?. I guess I'm having trouble understanding some parts of that bottom right quarter of the diagram.
Secondly, the PPPoE issue is just terminology. PPPoE can be used to refer to the whole Ethernet frame with the PPPoE session inside of it. It's also known as PPPoEoE which implies that there is no ATM layer. PPPoEoA is that Ethernet frame with the PPPoE session inside it but sent over the ATM adaption layer, rather that RFC LLC layer, or let's just say ATM for short. Protocol stacks will however show 'PPPoE' as a separate encapsulation layer, which it is, check any wireshark capture.
Thirdly, something I didn't realise and which CarlT mentioned on another post is that the MSAN encapsulates the PPPoE session in L2TP (previously I believed that L2TP session begins at the bRAS). It appears that L2TP is only used between the MSAN and bRAS when the backhaul is 802.1ad Ethernet rather than ATM. Also, I understand the GEA Cablelink now that BTw purchases from BT openreach.
Fourthly, I'm still not sure how the BTw core is connected to tier 1 ISPs and in what exact manner
-
The thing about PPPoE etc is just as you say, it can be one header, just the unique-to-PPPoE header, three headers PPP plus PPPoE plus Ethernet MAC, or protocol-in-context such as PPPoEoE ie ‘PPPoE on a LAN’, or PPPoEoA ‘PPPoE over ATM’ or ‘over ADSL’ and in these cases we could be referring to almost anything, even the whole protocol stack. It’s people such as me that promote these latter oEoX terms for disambiguation because it makes it clear which side of a modem were talking about. It is a bit messy and I am very likely one of the guilty ones using the term inconsistently. But for ADSL on the first mile there is one and only PPPoEoA protocol stack leaving aside the two variants of the RFC2684 shim layer in the middle. (The ‘LLC’ version of RFC2684 for PPPoEoA is the one that works on BT kit as I said before. Others may be able to help with other carriers. I can’t remember whether or not anyone has ever told me what the story is for PPPoEoA TT wholesale ADSL users. If so I forget.)
As for your third point. My ignorant guess based on no information was the same as you had though. I thought that on 21CN it was Ethernet from the DSLAM / MSAN (is it a grave sin to just always say DSLAM instead of MSAN, or not?) to the BRAS and L2TP started there. But if that were true it would have to be PPP over PPPoE over Ethernet from MSAN to BRAS as I don’t see how to send PPP in Ethernet frames straight, as it seems to have no defined exact method for doing it otherwise. (What ethertype would PPP naked in Ethernet frames have?) Anyway, exactly that was what I had always imagined. But CarlT corrects us and says that L2TP begins at the MSAN. As does Terry’s diagram. Does anyone have more references?
-
I recommend TR-101 - p 20 for the first mile, or what they call ‘the U point’ in that spec, that term is defined at the start of that document, where there is a reasonable diagram which could however use a bit more in the way of detail. On that page, b is PPPoEoA and d is PPPoA, the two you find with BT ADSL.
-
Now on p25 of TR101 we have protocol stacks for the ‘point V’, which is the link immediately upstream of the MSAN. This is one of the points that you and I are interested in.
So here’s the big question for this. Is 21CN TR-101? I have no idea. If not disregard all of this.
On p25 there’s no sign of L2TP, just Ethernet.
But who knows.
I wonder if we could look up the spec of some particular model of known MSAN hardware? It might say that it supports multiple options for upstream protocol stacks for all I know? Configurable per customer or something. And perhaps these docs like TR101 did not take off, or were adopted by some operators, or all. Or none.
-
Thirdly, something I didn't realise and which CarlT mentioned on another post is that the MSAN encapsulates the PPPoE session in L2TP (previously I believed that L2TP session begins at the bRAS). It appears that L2TP is only used between the MSAN and bRAS when the backhaul is 802.1ad Ethernet rather than ATM.
Did I say that the MSANs encapsulate PPP in L2TP or did I say that the MSE or BRAS does that?
https://www.btplc.com/SINet/sins/pdf/472v2p8.pdf
-
https://forum.kitz.co.uk/index.php/topic,21493.msg372055.html#msg372055
This was the post I was referring to. BTW, thanks for that SIN pdf, I've never seen that one before so I'll give that a read, it appears to have some nice diagrams on it. I recently found this https://www.btplc.com/SINet/sins/pdf/511v1p10.pdf which has a nice diagram on page 9.
-
Ah okay. Too long ago for me to remember where that came from, think I caveated it by remarking it could be done in a couple of ways and it seems to do the second of the two and transport everything over IP to the BRAS. CVLAN inside SVLAN and VPLS to impersonate a layer 2 network.
-
I just found this. Interesting what it says about the IEA, also wonder what he means by 'AMSAN' https://prezi.com/goctwzwtmk_z/bt-work-experience/. EDIT: http://www.fujitsu.com/ie/solutions/telecommunications/access-aggregation/ (Information on AMSANs)
-
Weaver, with regards to the V interface for PPPoA modems, this would be my guess (note, PPP|PPPoE|Eth = PPPoE).
For 20CN customers between DSLAM and bRAS (MSiP)
PPP|PPPoA|RFC2684|AAL5|ATM|SDH
For 21CN ADSL2+ / FTTC customers between MSAN and bRAS
PPP|PPPoE|802.1ad|Eth|SDH
I've also seen
PPP|L2TP|UDP|IP|Eth|SDH
I've also seen
PPP|PPPoE|Eth|L2TP|UDP|IP|Eth|SDH
-
Of your three guesses at the end, I had just told myself that it was the first one.
Sum-up/recap: Sorry, I got lost, and apologies if I misread CarlT, what is CarlT’s thinking?
-
Small detail but confused why you call the 20CN equipment a DSLAM and FTTC equipment a MSAN.
It's quite the opposite.
The FTTC kit technically are MSAN's, but are configured as DSLAM's only.
There are not many 20CN exchanges left.
For 21CN ADSL2+ / FTTC customers
I would completely separate 21CN ADSL2+ and FTTC.
Actually I would separate all NGA products (FTTC/G.FAST/FTTP) from ADSL2+.
The post again assumes FTTC uses PPP. It does not necessarily do so.
-
My thinking is that it doesn't really matter as things are going to be changing substantially in the not too distant anyway :)
-
j0hn is surely right that some ISPs do not use PPP, no ?
-
https://www.gabriel.urdhr.fr/2015/02/15/broadband-protocol-stack/ check the U interface weaver. If they don't use PPP I can only assume they're using 802.1x authentication
-
Nah. Can be done via DHCP options, MAC address or simply the CVLAN the traffic arrives on. Fair bet that the device connected to a customer's assigned DSLAM port is them.
Note BT Retail and the ability to use any username and password. BTW just uses the domain to pre-auth and that's all that's needed.
-
I agree with what Carl said - I was going to say that I seem to vaguely remember that some non-BT ISPs who have their own hardware in the exchange and so can do whatever they like do use DHCP from a remote DHCP server to replace certain functions that are otherwise delivered by PPP. This sometimes involves extensions to DHCP, which can have all sorts of options anyway, is very extensible. That’s only for IPv4 tho. I don’t know what the story is for IPv6 with such ISPs, can’t remember. In a case like that, someone’s router, which is acting as a local DHCP(v4) server for client machines on the LAN, is in fact acting as a relay in part. I have read the odd vague mention of such set-ups, but I don’t really know much about this.
As for IPv6, I use BT and my IPv6-related stuff is iirc entirely set up by static configuration so no need for any network info services. I do get IPv6CP over PPP iirc from my ISP Andrews and Arnold, and there possibly is config info actually available through it in my case, I forget. I am also unsure as I can’t think of a single case where I use any such network-supplied info for IPv6 config. I, like most people who have PPP, do get config info supplied for IPv4 via IPCP over PPP, but I don’t think I myself even use any of it.
-
https://www.gabriel.urdhr.fr/2015/02/15/broadband-protocol-stack/ check the U interface weaver. If they don't use PPP I can only assume they're using 802.1x authentication
Talktalk use IPoE with their own FTTC customers.
ISP's who wholesale Talktalk business are limited to PPP still.
Not 100% how they authenticate but there's certainly no credentials or Mac address from a fixed device.
Sky use DHCP Option 61 (they call it MER?) to authenticate.
Many many many modern broadband networks don't use PPP now. It's terribly inefficient when you start getting into higher throughput brackets.
OpenReach intended on ditching PPP for Ultrafast services (G.Fast/FTTP) but must have changed their mind.
-
Thanks, didn't think about dhcp authentication. BTW, i'm still not entirely sure about cvlans and svlans, just to get this straight, cvlan applied as it egresses from the street MSAN, SVLAN applied as it egresses through the GEA cable link..?
-
Thanks, didn't think about dhcp authentication. BTW, i'm still not entirely sure about cvlans and svlans, just to get this straight, cvlan applied as it egresses from the street MSAN, SVLAN applied as it egresses through the GEA cable link..?
https://www.btplc.com/SINet/sins/pdf/498v7p5.pdf
-
It's just a virtual way to split and manage traffic, particularly with different priorities.
The street MSANs are only operating as DSLAM's.
Only equipment in the exchange is used as a MSAN.
-
Basically DSLAM (Digital Subscriber Line Access Multiplexer) Multiplexes DSL connections
MSANs (Multi-Service Access Node) Multiplexes DSL and connects telephony & IPTV to the SP core.
FTTC cabs only deal with xDSL thus contain DSLAMs.
MSANs in the exchange (ie such as those used for adsl LLU) also have telephony interfaces.
-
Ah, telephony is the ‘multi’ bit. I had somehow never picked that up. Many thanks!
-
Until some months back I used to see entries in the BRAS column of AA’s clueless.aa.net control server which were names of the relevant BRAS that each of my three links was ultimately connected to. Then it changed, the names are now gone and all three show 213.1.180.152.
We show the name of the BRAS if we know it, we work out the name if there is reverse DNS set. In this case there isn't any reverse DNS for the IP address (yet) though. Having reverse DNS is useful and interesting, but BTW don't always add them; also sounds like this may be a new IP address if it has changed recently.
-
Thanks Andrew. I wondered why BT had changed it, whether it was just routine upgrading of kit or whether there had been a real redirection, rerouting of the geographical location.
-
When I wrote earlier about SDH, I'm pretty sure that it uses GTC + GEM between the ONU in the FTTC cab and the OLT, unless i'm mistaken
-
ONU in the cabinet? They use 1000base-BX connecting to ports on the cabinet's supervisor board. Nothing more complicated than that.
Some use WDM but same story, BX on different wavelengths multiplexed by external kit in the cabinet so it hits the DSLAM as simple BX.
Just saying you think they use GPON rather than trying to describe every protocol in the stack is fine.
The OLTs are multipurpose kit. They feed subscribers directly via PON ports and cabinets and indeed CableLinks to CPs via point to point Ethernet line cards. The Huawei OLTs can be the L2S.
-
I don't have any experience working at ISPs or the equipment but it's always been a gap in my knowledge that I've wanted to fill, I'm slowly ascertaining more and more through research, postulation, forums but it's never as good as actual pertinent hands on experience.
So openreach uses P2P not a GPON then for FTTC, interesting, I believe FTTP modems use GPON. Again with the SVLAN /CVLANs I understand the significance of a QinQ in GPON, the SVLAN provides a mapping to a GEM port and I believe it allows for flood domain shrinking to a specific GEM port associated with the SVLAN, and the CVLAN provides 801.1p CoS to the modem and service identification but with 1000base BX, despite reading the source you sent and a few others I haven't fully grasped the significance of a SVLAN in QinQ, I know the CVLAN provides 802.1p scheduling at the DSLAM and service identification at the modem but the SVLAN, why, could you perhaps state the importance of it, it seems to be grouping for different services again for the SP, what's the significance of this? is it used for determining the wavelength to use in the WDM kit? I. E. For iptv.
-
Again I think rather than reciting buzzwords and acronyms some thought about how networks are built would be a good plan. Serious case of trying to run before walking which will cause more confusion.
IPTV isn't going to use a separate wavelength. The whole point is that it's TV over IP. It uses the same IP network as broadband services. If it were on a separate wavelength it wouldn't be IPTV, it'd be using RFoG.
CVLANs face customers. SVLANs face service providers and have many CVLANs inside them. A single Service VLAN can carry 4096 Customer VLANs inside it. Service aggregation is a good thing. Rather than having thousands of CVLAN mappings between individual customers and service providers Openreach kit can use the SVLAN to make the decisions which CableLink and, hence, CP, they should switch the traffic too.
There's also the issue that the VLAN header is only 12 bits long which means a maximum of 4096 VLANs per layer 2 domain. Q-in-Q increases this to 16.7 million which allows scale. Without Q-in-Q operators could only terminate 4095 GEA customers on each BRAS.
-
A very nice concise recap.
-
I read that for IPoE, DHCP option 82 can be used for user authentication based on CVLAN/SVLAN but also IP source guarding I'd imagine? Theoretically the DSLAM could be configured to snoop DHCP handshakes and prevent MAC / IP addr spoofing. I'm not really sure how IP / MAC addr spoofing is mitigated for legacy ADSL2 customers whose data still passes through the MSAN in the exchange and where PPP/L2TP is used, I'd imagine it could be possible for the BRAS to maintain PPPoE session ID - MAC addr bindings and similarly for the ISP gateway to maintain IPCP configured IP addrs - TunnelID/SessionID bindings. Just a intuitive conjecture but I don't know.
Furthermore I assume the DSLAM adds the CVLAN + SVLAN, I assume that a unique QinQ pairing is assigned to each DSLAM port connected to the BRAS and when it arrives at the L2S it switches it to the correct GEA cablelink. Correct me if I'm wrong but that's the most recent mental picture I have.
The bRAS sets up a pseudowire to the ISP gateway (selects ISP based on SVLAN?) over the MPLS backbone and the ISP gateway authenticates based on option 82, 61, something like that.
Finally, does the EEA act as the MSE bRAS and the 21C bRAS at the core node functions as a regular P router?
You said about buzzwords, forgive me, my knowledge of WANs isn't the best.
-
I may be totally misunderstanding, because I'm not quite sure where this thread is leading.
>> , I'd imagine it could be possible for the BRAS to maintain PPPoE session ID
>> I'm not really sure how IP / MAC addr spoofing is mitigated for legacy ADSL2 customers whose data still passes through the MSAN in the exchange and where PPP/L2TP is used,
PPP authentication is ISP responsibility and performed by the ISP RADIUS which assigns the IP address. BTWholesale also use Service Selection Barring (https://kitz.co.uk/adsl/equip2.htm#authentication) on their network to ensure that the EU can only connect to the correct ISP. There may be times during migration when there is an overlap of 2 ISPs and they used to allow a week or two on both SP domains.
There's an old diagram here for the 20CN network, but there may be a more up to date one on SINET for 21CN
https://kitz.co.uk/adsl/images/l2tpauthentication.gif