|
|
New Cisco MPLS Features |
|
| Peter J. Welcher | |
|
||||||||||||
IntroductionI'm writing this in early July in Tokyo, two weeks into "Pete's Asia-Pac Tour". Thanks to NIL (www.nil.si ) and Cisco for the chance to teach two weeks of SE classes in Tokyo (Router Architecture, QoS, MPLS)! And thanks to HP Taiwan for the chance to visit Taipei to consult with and train folks on MPLS technology, capabilities, and design! Eating my way around the capitals of the two countries has been fun! Not to mention weekend/evening sight-seeing.This week's article is going to take a look at some new or coming
Cisco MPLS features, as well as other recent Cisco MPLS announcements.
There are a lot more good IETF RFC and draft documents pertaining
to MPLS. The best way to find recent developments is to visit the
IETF Working Groups pages. If you're interested in MPLS, you'll
want the MPLS, TEWG, and PWE3 working groups (see below). You may
also find PPVPN of interest.
Adobe Acrobat PDF versions of the Cisco Networkers 2002 talks from San Diego are available online, and the MPLS talks were particularly well-organized and clear this year. Recommended highly! (I'm not giving you the URL since I'm not sure Cisco wants it publicly posted yet.) What Is ATOM?Any Transport Over MPLS (ATOM) is the most recent MPLS development from Cisco. It is soon to be shipping basic functionality (12.0(22) SY for 7200/7500, 12.0(23) or (24) S for 12000 GSR). ATOM Phase I should provide for like-to-like transport of Frame Relay, ATM AAL5 cells, or Ethernet frames across an MPLS network. Parts like Ethernet Over MPLS and ATM AAL5 Over MPLS may already be shipping in some devices.A later phase is intended to allow any-to-any connections. Transparent transport of trunking is also planned but not yet available. That is, Ethernet over MPLS (EoMPLS) can only currently be configured at the VLAN level. Packet Over SONET Over MPLS (POSoMPLS) is also planned. Plus transport of general ATM cells. Plus more features! Target platforms: 12000 GSR, 7200, 7500. (So those of us using 2600/3600 for our MPLS test and practice labs may not be able to try this out for a while yet.) Why ATOM?The key idea here is to provide Layer 2 VPN services over IP-based MPLS networks (with better economics than using classical ATM gear).You may be wondering: "Why is this a Good Thing?" Or "I thought Layer 3 MPLS VPN was the hot technology." A previous article covered Layer 3 MPLS VPN's. We saw that these had a lot of advantages, both to Service Provider (SP) and customer, but they do require mingling customer and SP routing. Some customers may however just want connectivity (particularly at commodity pricing for connectivity without additional services). Layer 2 VPN's address this market. They just provide a Layer 2 link, no routing, no other services. They also eventually allow the inversion of services: instead of IP over ATM over SONET, we can perhaps see a transition to ATM or POS over MPLS (over IP) as prices for Gigabit Ethernet and faster gear plummet. The Cisco ATOM Layer 2 VPN's also use a common IP and MPLS infrastructure with the Layer 3 VPN's. They look like they should scale well, in terms of not adding great complexity or memory or CPU usage in MPLS routers (LSR's) already offering RFC 2547-based MPLS VPN's. Label distribution and the IGP routing protocol automatically set up a full mesh of label paths from PE to PE. These are used to transport Layer 3 MPLS VPN traffic between VRF's in the PE's. They can now also be used as traffic trunks carrying many Layer 2 MPLS VPN's between the same PE's. This strikes me as similar to the idea of Virtual Path switching in SP-scale ATM switches. Cisco's implementation of ATOM uses directed LDP sessions for signalling. The alternative (draft by Kompella) uses BGP for signalling. Cisco has proposed an alternative (draft by Rosen). Discussion of the best approach appears to be continuing. Virtual LAN services are anticipated for the future. They might be called Virtual Private LAN Services (VPLS). When doing VPLS, the MPLS network acts like a giant distributed Ethernet switch, with PE's acting as edge bridges or switches. I'm not sure I like this idea: I currently design to keep Spanning Tree (STP) to very small scale in campuses. Campuses I or my peers design have many Layer 3 switching points. And the network are generally very stable. I or my peers have seen some pure Layer 2 campues "melt down" when someone accidentally created a Spanning Tree loop. That's an event you hope to experience at most once. Most sites that have seen it do not wish to ever see it again! Outages are bad; campus-wide outages are really bad! Having STP running from many companies across a shared MAN or WAN backbone scares me. I'd like to be convinced this is a sane act. All the vendors seem pursuing this for the MAN optical arena. I find myself wondering whether this means the optical / Service Provider folks haven't talked to the Campus Switching people about scaling and what works (and what doesn't work). I also recall wondering about ATM LANE fanatics telling us, in effect, how wonderful broadcasts across the ATM WAN were the future. Bandwidth never got inexpensive enough. Does that still apply? One alternative that does come to mind: as virtual LAN services evolve, perhaps we'll see fewer small site routers. Maybe small sites will look like different VLAN's running into a central site router, in the typical small-medium corporate network of the future. That keeps the STP domain size down, although it does assume broadcasts across the WAN become a non-issue, in terms of cost. To find Cisco materials on ATOM, look under VPN's, under the Unified
VPN Suite (3rd link below
). In addition to the links listed below, there are links to
public presentations and other interesting materials!
How Does ATOM Work?The "magic" used here is relatively simple, if you're already used to MPLS. Just as with Layer 3 MPLS VPN's, we need a LSP label path between any two PE routers for ATOM to work. The layer 2 frames arrive at one PE, are encapsulated, and are sent to the corresponding PE at the other end of the "Layer 2 Pseudo-Wire". The egress PE removes the encapsulation and sends out the layer 2 frame.The encapsulation used adds three headers:
In ATOM then, the outermost label (tunnel header) is thus a normal LSP label from the IGP (Internal Gateway Protocol) route to the destination PE. The demultiplexer label comes from directed LDP between the PE routers, caused by our configuration telling the routers to set up a virtual circuit ("pseudo-wire"). There are lots of details as to the type codes to use, how and what to encode in the control word (FECN, BECN, etc.). We'll skip those -- see also the drafts with "martini" in the name, above. If there is a problem, the PE router is required to use Frame Relay LMI and supposed to use ATM ILMI to notify what is connected that the circuit has gone down. The PE router is also supposed to withdraw the label assigned to the pseudo-wire. Configuring this is reasonably straight-forward. Samples from what's documented for EoMPLS (e.g. on 7600): interface GigabitEthernet0/0.1This tells the router to take 802.1q VLAN 30, and provide a Virtual Circuit (VC) or Pseudo-Wire (PW) with ID 300 to 1.0.0.2. The other PE, 1.0.0.2, needs a matching configuration command. Note that cross-connecting VLAN's, e.g. VLAN 4 to VLAN 5, may have interesting STP (Shared Spanning Tree with PVST+) effects and surprises, and is not advisable. The "sequencing" option causes enforcement of in-sequence frame delivery by means of sequence numbers. Sample HDLC serial port connectivity (preliminary sample) is similar: interface Serial 1/0:0This also can be done with PPP as encapsulation, same commands, just add "encapsulation ppp". interface ATM1/0.100 Recent Cisco MPLS AnnouncementsThe general title for this set of announcements was MPLS for Shared Services. Included are four features that can enable shared services for MPLS VPN customers of a Service Provider. The presentation below explains how these are helpful to SP's wishing to provide more managed services to their customers.
Other MPLS TopicsTopics that came to mind as worthy of more discussion. But not in this article, which is getting too long!
ConclusionIf you haven't checked out NIL's remote labs, you might want to. Good labs (in English!) on OSPF, BGP, QoS, MPLS, can be rented and operated remotely. See www.nil.si . Virtual classroom and Web-based training are also available. Ivan Pepelnjak of NIL is co-author of the MPLS and VPN Architectures book by Cisco Press. The CCIP edition just came out, fixing some typos and generally improving on the first edition.Interesting reading: recent Cisco presentations (Networkers, also the above MPLS Shared Services presentation) cite Cisco MPLS as being in use in 140 deployments today. The Cisco news pages also have some interesting reading about Bell Canada's deployment of IP MPLS based VPN's. Customers apparently use a Web interface to select QoS and bandwidth on demand. Also exciting: Cisco's new routing convergence options (Networkers 2002) and the GRIP announcements. These topics perhaps would fit well with a 1-2 article series on High Availability. Prior to (and during) this road trip, I and the other folks of Chesapeake NetCraftsmen have been doing some exciting and interesting consulting. (Thanks to those who brought us in to work with them!) I'm considering an article about new trends in corporate networks, based on what we've been seeing. Anonymous of course, to protect our clients. Our work includes some large switched campus networks, one company with mainframe diversity and 30 Gbps of FICON/ESCON over MAN dark fiber, another looking at a new WAN network with voice and data sharing the same links. It also includes a major debit card organization. And design and implementation and sequencing of MPLS features for a nation-wide MPLS network supporting GPRS and 3G voice as well as data. If you think my comments about Virtual LAN services are overly negative, conservative, or that I'm just showing my age, please let me know! I'd love to debate it by email, or try to understand other points of view on this! Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net . 7/9/2002Copyright (C) 2002, Peter J. Welcher |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
