It stands for Multiprotocol Label Switching. It’s a way of speeding up network traffic by avoiding the time it takes for a router to lookup the address of the next node to send a packet to. In an MPLS network data has a label attached to it, and the path that is taken is based on the label. Additionally, you can also attach a class to the data, which can be used to indicate that data has higher than usual priority.
Whilst the above takes care of the ‘Label Switching’ part of the name, the Multiprotocal part comes from the fact that Asynchronous Transport Mode (ATM), Internet Protocol (IP), and frame relay network data can all be sent using MPLS. For most companies, MPLS will be a service that they buy from a network services provider, and it might be beneficial to think of it thus: a pair of routers (the idea of a pair is important) on either side of an ‘MPLS cloud’. Example: you have two offices you want to link – say London and Edinburgh. You have in each office a router which interfaces with the MPLS service. When a device in Edinburgh wants to send data to a device in London it is sent via the Edinburgh router onto the MPLS service (appropriately labelled and classified by the router) where it will appear (eventually) on the London router for passing to the correct device. Between the two routers (referred to as ‘edge routers’ because they sit on the edge of the MPLS service) the data is the responsibility of the network services provider. For this reason, an MPLS service is often referred to as a cloud in network diagrams (‘we don’t know or care what happens here’). So why bother? From the handful of customers we know using these services, the MPLS service is replacing leased lines. One of the key drivers seems to be cost – the MPLS services are working out cheaper than a leased line. However, another driver seems to be the desire to offer new services to users, one of which is Voice over IP (usually shortened to VoIP). MPLS can be a sound (heh) choice for VoIP because of the idea of prioritising and classifying data. For VoIP to work, packets need to be sent quickly and at a relatively stable speed – otherwise, you get distortions on the line. Therefore, MPLS will offers the promise of ‘first class mail’ data packets (voice) and ‘2nd class mail’ (data) over the same network path (data is less sensitive to speed of transmission and variance of speed of transmission). On Thu, Jul 1, 2010 at 9:20 AM, Josh Patten <jpat...@co.brazos.tx.us> wrote: > I've never done anything like that before, but I guess it sounds like a > winner... > > In any case 1 T1 isn't going to cut the mustard when running 40 phones and > that many departments. I have a site with 6 people and 7 phones and I had to > put a secondary proxy out there because the signalling wasn't reliable (yes > I had QoS set up properly). > > Josh Patten > Assistant Network Administrator > Brazos County IT Dept. > (979) 361-4676 > > > On 7/1/2010 8:16 AM, Tony Graziano wrote: > > Might I suggest a private MPLS cloud instead of the T1's with tagging for > voice... this way he can use VVX's out on the fringe and we all know how > fond of those he is. > > On Thu, Jul 1, 2010 at 9:15 AM, Josh Patten <jpat...@co.brazos.tx.us>wrote: > >> Might I suggest putting a redundant proxy out at the remote location and >> configuring your DNS like this: >> http://wiki.sipfoundry.org/display/xecsuser/Location+based+DNS+views+for+sipXecs+using+BINDso >> all phones at that location register to that redundant proxy. >> >> >From experience I would get a second point-to-point data T1 to that >> location dedicated to voice. Having that many users chewing up your T1 PLUS >> phones is just asking for trouble. >> >> Josh Patten >> Assistant Network Administrator >> Brazos County IT Dept. >> (979) 361-4676 >> >> >> On 7/1/2010 7:08 AM, Nathaniel Watkins wrote: >> >> The remote contains these offices (I’m not sure what some of these >> offices due – some are State/Federal offices): >> >> Public Utilities >> >> Permits & Inspections >> >> Extension Office >> >> NRCS & GSCD >> >> Farm Service Agency >> >> Rural Development >> >> Election Board >> >> >> >> I totally agree that putting all your eggs in one T1 basket sounds like >> crazy talk – however… >> >> >> >> Here are thoughts/concerns with a totally separate sipXecs install: >> >> 1) Manageability >> >> a. Patton will require additional routing rules for base >> functionality >> >> b. Additional dialing rules to route between sipxósipxóNECóetc. >> >> c. Greatly complicates the overall design >> >> 2) Functionality >> >> a. End users are expecting the capability to plug their phones in >> and just work (at any county location) – if we are routing DID’s to the >> remote – and they plug their phones in at our Emergency Operations Center – >> it needs to just ring there >> >> 3) Costs >> >> a. One of the driving factors is reducing costs – having a ‘server’ >> (granted could be an inexpensive one), plus failover trunks (handful of POTS >> lines), plus additional analog gatways. We are then looking at $2,000 >> capital costs and $1,000 annual operating costs. This greatly drives down >> the ROI and it seems hard to justify those costs coupled with the added >> complexity of managing separate servers (plus having multiple DNS/DHCP >> scopes). All to work around a potential 2% business interruption >> (considering a potential 1 week down time hazard). >> >> >> >> A HA install could be a compromise, but that introduces its own issues - >> Perhaps a good compromise of a unified system and failover would be to have >> a second route between sites; i.e. have a site to site vpn over the >> internet that would be a backup link. In the event of a T1 failure, we >> could route traffic over said connection? >> >> >> >> In a perfect world, I’d love to have a single, simple to manage phone >> system. Not 5 separate systems that I have to link together and have >> equipment all over the place that I have to keep tabs on. Of course, I’d >> also like to not get fired for killing all of our phones J >> >> >> >> >> >> Nathaniel Watkins >> IT Director >> Garrett County Government >> 203 South 4th Street, Room 210 >> Oakland, MD 21550 >> Telephone: 301-334-5001 >> Fax: 301-334-5021 >> E-mail: nwatk...@garrettcounty.org >> >> >> >> *From:* sipx-users-boun...@list.sipfoundry.org [ >> mailto:sipx-users-boun...@list.sipfoundry.org<sipx-users-boun...@list.sipfoundry.org>] >> *On Behalf Of *Tony Graziano >> *Sent:* Thursday, July 01, 2010 3:01 AM >> *To:* maybelater >> *Cc:* sipx-users@list.sipfoundry.org >> *Subject:* Re: [sipx-users] sipx-users Digest, Vol 76, Issue 154 >> >> >> >> Nathaniel, >> >> >> >> It really needs to be an analysis of "how that branch" functions. >> Depending on the role the branch serves within the organization in the event >> of any "natural disaster", especially for intra-office communication, >> relying on a T1 to call down the hall, upstairs, downstairs, etc, is perhaps >> "nonsensical". >> >> >> >> A local PSTN gateway for inbound calls to be redirected for a main number, >> and for emergency outbound calling pretty well insulates it. With forty or >> so workers, 1 T1 only goes so far when it comes to calls:bandwidth. Of >> course, for branches with enough users, I always stick with a dedicated >> system per branch as I like a higher level of functionality when something >> goes down. For instance, if the T1 goes down and they can no longer make >> enterprise calls to other branches, they can dial the published number via a >> "copper rule" for dialing out via PSTN on a local gateway (as well as 911). >> >> >> >> Ultimately there has to be a "weight" to gauge what needs to be available, >> and how efficient and connected the branch stays in an outage. With a >> separate system the users can: >> >> >> >> 1. Continue t have their phones register. >> >> 2. Call each other. >> >> 3. Check voicemail. >> >> 4. Dial around to call out via alternate gateway (analog/siptrunk). >> >> 5. Call from their desk to bug you to ask you why you haven't fixed it >> yet. >> >> 6. Call other branches via their PSTN published number. >> >> >> >> Calling patterns, roles and survivability are all factors. >> >> On Thu, Jul 1, 2010 at 2:26 AM, maybelater <maybela...@gmx.de> wrote: >> >> I might not be able to configure sipx the way I want, but been working in >> sales and system-consulting for 4 years now. >> >> -breakdown of business telephony is major business killer >> -according to Murphy your T1 WILL break down as soon as you rely on it too >> much >> -rerouting to mobile is great, but what about outbound calls ? >> -need of local PSTN-Gateways is totally dependent on the task your >> coworkers >> on the remote site are doing, the availability they need for their >> telephony >> >> I am a strong believer in centralization, thus I would just configure them >> on the central PBX, but there are (of course) scenarios where the customer >> Or the situation demands the best possible availability >> >> >> -----Ursprüngliche Nachricht----- >> Von: sipx-users-boun...@list.sipfoundry.org >> [mailto:sipx-users-boun...@list.sipfoundry.org] Im Auftrag von >> sipx-users-requ...@list.sipfoundry.org >> Gesendet: Donnerstag, 1. Juli 2010 05:10 >> An: sipx-users@list.sipfoundry.org >> Betreff: sipx-users Digest, Vol 76, Issue 154 >> >> Send sipx-users mailing list submissions to >> sipx-users@list.sipfoundry.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://list.sipfoundry.org/mailman/listinfo/sipx-users >> or, via email, send a message with subject or body 'help' to >> sipx-users-requ...@list.sipfoundry.org >> >> You can reach the person managing the list at >> sipx-users-ow...@list.sipfoundry.org >> >> When replying, please edit your Subject line so it is more specific than >> "Re: Contents of sipx-users digest..." >> >> _______________________________________________ >> sipx-users mailing list sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> >> >> >> >> -- >> ====================== >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: tgrazi...@voice.myitdepartment.net >> Fax: 434.984.8431 >> >> Email: tgrazi...@myitdepartment.net >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: helpd...@voice.myitdepartment.net >> Fax: 434.984.8427 >> >> Helpdesk Contract Customers: >> http://www.myitdepartment.net/gethelp/ >> >> Why do mathematicians always confuse Halloween and Christmas? >> Because 31 Oct = 25 Dec. >> >> ------------------------------ >> This message and any files transmitted with it are intended only for the >> individual(s) or entity named. If you are not the intended individual(s) or >> entity named you are hereby notified that any disclosure, copying, >> distribution or reliance upon its contents is strictly prohibited. If you >> have received this in error, please notify the sender, delete the original, >> and destroy all copies. Email transmissions cannot be guaranteed to be >> secure or error-free as information could be intercepted, corrupted, lost, >> destroyed, arrive late or incomplete, or contain viruses. Garrett County >> Government therefore does not accept any liability for any errors or >> omissions in the contents of this message, which arise as a result of email >> transmission. >> >> >> Garrett County Government, >> 203 South Fourth Street, Courthouse, Oakland, Maryland 21550 >> www.garrettcounty.org >> >> >> _______________________________________________ >> sipx-users mailing list sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> >> >> _______________________________________________ >> sipx-users mailing list sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
