Network Enhancers - "Delivering Beyond Boundaries" Headline Animator

Saturday, June 30, 2012

Advanced MPLS Interview Questions - Part 2

1. What group is responsible for creating MPLS standards?

The IETF's MPLS Working Group is charged with establishing core MPLS standards. Other IETF working groups are charged with developing standards covering areas such as Generalized MPLS, MPLS network management, Layer 2 encapsulation, L2 & L3 VPN services, and MPLS Traffic Engineering.

In addition, industry groups such as the Optical Internetworking Forum (OIF), The Optical Ethernet Forum, and the MFA Forum (MPLS/Frame/ATM) are working on other MPLS standards not related to the areas of focus of the IETF.

2. What is the MFA Forum?

The MFA is the union of the MPLS Forum, Frame Relay Forum, and ATM Forum. The MFA is an industry consortium dedicated to accelerating the adoption of Multiprotocol Label Switching (MPLS) and its associated technologies.

3. What MPLS related mailing lists are there and what are they used for?

There following is a list of current MPLS-related mailing lists:
The IETF's MPLS Working Group mailing list, which can be joined https://www1.ietf.org/mailman/listinfo/mpls. This list is for discussion of MPLS standards development. Note that several of the other IETF working groups also host mailing lists for discussion of MPLS standards for specific applications.

The MPLS-OPS mailing list, which can be joined by visiting http://www.mplsrc.com/mplsops.shtml. This list is for the discussion of issues related to the design, deployment and management of MPLS-based networks

LINUXMPLS - A Yahoo-based group and mailing list for the discussion of MPLS implementations for LINUX can be accessed at:

http://groups.yahoo.com/group/linuxmpls

4. What is MPLS?

MPLS stands for "Multiprotocol Label Switching". In an MPLS network, incoming packets are assigned a "label" by a "label edge router (LER)". Packets are forwarded along a "label switch path (LSP)" where each "label switch router (LSR)" makes forwarding decisions based solely on the contents of the label. At each hop, the LSR strips off the existing label and applies a new label which tells the next hop how to forward the packet.

Label Switch Paths (LSPs) are established by network operators for a variety of purposes, such as to guarantee a certain level of performance, to route around network congestion, or to create IP tunnels for network-based virtual private networks. In many ways, LSPs are no different than circuit-switched paths in ATM or Frame Relay networks, except that they are not dependent on a particular Layer 2 technology.

An LSP can be established that crosses multiple Layer 2 transports such as ATM, Frame Relay or Ethernet. Thus, one of the true promises of MPLS is the ability to create end-to-end circuits, with specific performance characteristics, across any type of transport medium, eliminating the need for overlay networks or Layer 2 only control mechanisms.

To truly understand "What is MPLS", RFC 3031 - Multiprotocol Label Switching Architecture, is required reading.


5. How did MPLS evolve?

MPLS evolved from numerous prior technologies including Cisco's "Tag Switching", IBM's "ARIS", and Toshiba's "Cell-Switched Router". More information on each of these technologies can be found at http://www.watersprings.org/links/mlr/.

The IETF's MPLS Working Group was formed in 1997.

6. What problems does MPLS solve?

The initial goal of label based switching was to bring the speed of Layer 2 switching to Layer 3. Label based switching methods allow routers to make forwarding decisions based on the contents of a simple label, rather than by performing a complex route lookup based on destination IP address. This initial justification for technologies such as MPLS is no longer perceived as the main benefit, since Layer 3 switches (ASIC-based routers) are able to perform route lookups at sufficient speeds to support most interface types.

However, MPLS brings many other benefits to IP-based networks, they include:

Traffic Engineering - the ability to set the path traffic will take through the network, and the ability to set performance characteristics for a class of traffic

VPNs - using MPLS, service providers can create IP tunnels throughout their network, without the need for encryption or end-user applications

Layer 2 Transport - New standards being defined by the IETF's PWE3 and PPVPN working groups allow service providers to carry Layer 2 services including Ethernet, Frame Relay and ATM over an IP/MPLS core

Elimination of Multiple Layers - Typically most carrier networks employ an overlay model where SONET/SDH is deployed at Layer 1, ATM is used at Layer 2 and IP is used at Layer 3. Using MPLS, carriers can migrate many of the functions of the SONET/SDH and ATM control plane to Layer 3, thereby simplifying network management and network complexity. Eventually, carrier networks may be able to migrate away from SONET/SDH and ATM all-together, which means elimination of ATM's inherent "cell-tax" in carrying IP traffic.

7. What is the status of the MPLS standard?

Most MPLS standards are currently in the "Internet Draft" phase, though several have now moved into the RFC-STD phase. See "MPLS Standards" for a complete listing of current ID's and RFC's. For more information on the current status of various Internet Drafts, see the IETF's MPLS Working Group home page at http://www.ietf.org/html.charters/mpls-charter.html

There's no such thing as a single MPLS "standard". Instead there a set of RFCs and IDs that together allow the building of an MPLS system. For example, a typical IP router spec. sheet will list about 20 RFCs to which this router will comply. If you go to the IETF web site (http://www.ietf.org), then click on "I-D Keyword Search", enter "MPLS" as your search term, and crank up the number of items to be returned, (or visit http://www.mplsrc.com/standards.shtml) you'll find over 100 drafts currently stored. These drafts have a lifetime of 6 months.

Some of these drafts have been adopted by the IETF WG for MPLS. The filename for these drafts is prefixed by "draft-ietf-". Some of these drafts are now on the IETF Standards Track. This is indicated in the first few lines of the document with the term "Category: Standards Track". You can read up on this process in RFC 2600.

MPLS Components

8. What is a Label?

Section 3.1 of RFC 3031: "Multiprotocol Label Switching Architecture" defines a label as follows "A label is a short, fixed length, locally significant identifier which is used to identify a FEC. The label which is put on a particular packet represents the "Forwarding Equivalence Class" to which that packet is assigned."

The MPLS Label is formatted as follows:

-20bits Label--3bits CoS--1bit Stack--8bits TTL-

The 32-bit MPLS label is located after the Layer 2 header and before the IP header. The MPLS label contains the following fields:

The label field (20-bits) carries the actual value of the MPLS label.

The CoS field (3-bits) can affect the queuing and discard algorithms applied to the packet as it is transmitted through the network.

The Stack (S) field (1-bit) supports a hierarchical label stack.

The TTL (time-to-live) field (8-bits) provides conventional IP TTL functionality. This is also called a "Shim" header.

9. What is a Label Switch Path?

An LSP is a specific path traffic path through an MPLS network. An LSP is provisioned using Label Distribution Protocols (LDPs) such as RSVP-TE or CR-LDP. Either of these protocols will establish a path through an MPLS network and will reserve necessary resources to meet pre-defined service requirements for the data path.

LSPs must be contrasted with traffic trunks. From RFC 2702: "Requirements for Traffic Engineering Over MPLS," "A traffic trunk is an aggregation of traffic flows of the same class which are placed inside a LSP. It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses. In practice, the terms LSP and traffic trunk are often used synonymously. The path through which a trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks."

10. What is a Label Distribution Protocol?

A label distribution protocol (LDP) is a specification which lets a label switch router (LSR) distribute labels to its LDP peers. When a LSR assigns a label to a forwarding equivalence class (FEC) it needs to let its relevant peers know of this label and its meaning and LDP is used for this purpose. Since a set of labels from the ingress LSR to the egress LSR in an MPLS domain defines a Label Switched Path (LSP) and since labels are mapping of network layer routing to the data link layer switched paths, LDP helps in establishing a LSP by using a set of procedures to distribute the labels among the LSR peers.

Label Switching Routers (LSRs) use labels to forward traffic. A fundamental step to Label Switching is that LSRs agree on the what labels they should use to forward traffic. They come to this common understanding by using the Label Distribution

Label Distribution Protocol is a major part of MPLS. Similar mechanisms for Label exchange existed in vendor implementations like Ipsilonâs Flow Management Protocol (IFMP), IBMâs Aggregate Route-based IP Switching (ARIS), and Ciscoâs Tag Distribution Protocol. LDP and labels are the foundation of Label Switching.

LDP has the following basic characteristics:

It provides an LSR discovery mechanism to enable LSR peers to find each other and establish communication
It defines four classes of messages: DISCOVERY, ADJACENCY, LABEL ADVERTISEMENT, and NOTIFICATION messages
It runs over TCP to provide reliable delivery of messages (with the exception of DISCOVERY messages
LDP label distribution and assignment may be performed in several different modes:


Unsolicited downstream versus downstream-on-demand label assignment
Order versus independent LSP control
Liberal versus conservative label retention

11. What's the difference between CR-LDP and RSVP-TE

CR-LDP and RSVP-TE are both signaling mechanisms used to support Traffic Engineering across an MPLS backbone. RSVP is a QoS signaling protocol that is an IETF standard and has existed for quite some time. RSVP-TE extends RSVP to support label distribution and explicit routing while CR-LDP proposed to extend LDP (designed for hop-by-hop label distribution to support QoS signaling and explicit routing). MPLS Traffic Engineering tunnels are not limited to IP route selection procedures and thus will spread network traffic more uniformly across the backbone taking advantage of all available links. A signaling protocol is required to set up these explicit MPLS routes or tunnels.


There are many similarities between CR-LSP and RSVP-TE for constraint-based routing. The Explicit Route Objects that are used are extremely similar. Both protocols use ordered Label Switched Path (LSP) setup procedures. Both protocols include some QoS information in the signaling messages to enable resource allocation and LSP establishment to take place automatically.

At the present time CD-LDP development has ended and RSVP-TE has emerged as the "winner" for traffic engineering protocols.


12. What is a "Forwarding Equivalency Class"?


Forwarding Equivalency Class (FEC) is a set of packets which will be forwarded in the same manner (e.g., over the same path with the same forwarding treatment). Typically packets belonging to the same FEC will follow the same path in the MPLS domain. While assigning a packet to an FEC the ingress LSR may look at the IP header and also some other information such as the interface on which this packet arrived. The FEC to which a packet is assigned is identified by a label.

One example of an FEC is a set of unicast packets whose network layer destination address matches a particular IP address prefix. A set of multicast packets with the same source and destination network layer addresses is another example of an FEC. Yet another example is a set of unicast packets whose destination addresses match a particular IP address prefix and whose Type of Service bits are the same

13. How are Label Switch Paths built?


A Label Switch Path (LSP) is a set of LSRs that packets belonging to a certain FEC travel in order to reach their destination. Since MPLS allows hierarchy of labels known as label stack, it is possible to have different LSPs at different levels of labels for a packet to reach its destination. So more formally, a LSP of a packet with a label of level m is a set of LSRs that a packet p has to travel at level m to reach its destination. Please refer to 3.15 of RFC 3031 - Multiprotocol Label Switching Architecture, for a very formal and complete definition.



g. What is the relationship between MPLS and the Interior Routing Protocol

Interior Gateway Protocols (IGP), such as OSPF and IS-IS, are used to defined reachability and the binding/mapping between FEC and next-hop address. MPLS learns routing information from IGP (e.g., OSPF, IS-IS). Link-state Interior Gateway Protocol is typically already running on large Corporations or Service Providers networks There are no changes required to IGP routing protocols to support MPLS, MPLS-TE, MPLS QoS, or MPLS-BGP VPNs.

14. What other protocols does MPLS support besides IP?


By definition, Multiprotocol Label Switching supports multiple protocols. At the Network Layer MPLS supports IPv6, IPv4, IPX and AppleTalk. At the Link Layer MPLS supports Ethernet, Token Ring, FDDI, ATM, Frame Relay, and Point-to-Point Links. It can essentially work with any control protocol other than IP and layer on top of any link layer protocol. In addition, development efforts have allowed MPLS to not only work over any data link layer protocol, but also to natively carry a data link layer protocol over IP, thus enabling services such as Ethernet over MPLS.

MPLS and ATM


15. What are the differences between MPLS and ATM?

MPLS brings the traffic engineering capabilities of ATM to packet-based network. It works by tagging IP packets with "labels" that specify a route and priority. It combines the scalability and flexibility of routing with performance and traffic management of layer 2 switching. It can run over nearly any transport medium (ATM, FR, POS, Ethernet...) instead of being tied to a specific layer-2 encapsulation. As it uses IP for its addressing, it uses common routing/signaling protocols (OSPF, IS-IS, RSVP...)


16. Does MPLS replace ATM?


MPLS was not designed to replace ATM but, the practical reality of the dominance of IP-based protocols coupled with MPLS's inherent flexibility has led many service providers to migrate their ATM networks to one based on MPLS.


MPLS can co-exist with ATM switches and eliminate complexity by mapping IP addressing and routing information directly into ATM switching tables. The MPLS label-swapping paradigm is the same mechanism that ATM switches use to forward ATM cells. For ATM-LSR the label swapping function is performed by the ATM forwarding component. Label information is carried in the ATM Header, specifically the VCI and VPI fields. MPLS provides the control component for IP on both the ATM switches and routers. For ATM switches PNNI, ATM ARP Server, and NHRP Server are replaced with MPLS for IP services. The ATM fowarding plane (i.e 53-byte cells) are preserved. PNNI may still used on ATM switches to provide ATM services for non-MPLS ports. Therefore, an IP+ATM switch delivers the best of both worlds; ATM for fast switching and IP protocols for IP services all in a single switch.


17. What is "Ships in the night"?


Some vendors support the running of MPLS and ATM in the same device. Generally speaking, these two processes run separately. A change in an MPLS path has no bearing on ATM virtual circuits. This practice is commonly referred to "ships in the night" since the two processes act alone. However, in some cases, there is some interaction between the two processes. For example, some vendors support a mechanism whereby a reservation of resources by a label switch path is detected by the ATM control mechanism to avoid resource conflicts.

"Ships in the night" is used as a transitioning mechanism as networks migrate their ATM control planes to MPLS. Networks initially preserve ATM for carrying time sensitive data traffic such as voice and video, and for connecting to non-MPLS enabled nodes, while concurrently running MPLS to carry data. Over time there will no longer be a need for separate ATM flows and therefore networks will only carry MPLS label-based traffic.


MPLS Traffic Engineering


18. What does MPLS traffic engineering accomplish?

Traffic engineering refers to the process of selecting the paths chosen by data traffic in order to balance the traffic load on the various links, routers, and switches in the network. Traffic engineering is most important in networks where multiple parallel or alternate paths are available.


A major goal of Internet Traffic Engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance.

The goal of TE is to compute a path from one given node to another (source routing), such that the path does not violate the constraints (e.g. Bandwidth/administrative requirements...) and is optimal with respect to some scalar metric. Once the path is computed, TE (a.k.a. Constraint based routing) is responsible for establishing and maintaining forwarding state along such a path.

19. What are the components of MPLS-TE?

In order to support Traffic engineering, besides explicit routing (source routing), the following components should be available:

Ability to compute a path at the source by taking into account all the constraints. To do so the source need to have all the information either available locally or obtained from other routers in the network (e.g. Network topology)

Ability to distribute the information about network topology and attributes associated with links throughout the network once the path is computed, need a way to support forwarding along such a path

Ability to reserve network resources and to modify link attributes (as the result of certain traffic taking certain routes)

MPLS TE leverages several foundation technologies:

Constraint shortest path first algorithm used in path calculation. This is a modified version of the well known SPF algorithm extended to constraints support

RSVP extension used to establish the forwarding state along the path, as well as to reserve resources along the path

Link state IGPs with extension (OSPF with Opaque LSAs, IS-IS with Link State Packets TLV (type, length, value)) keeping track of topology changes propagation


20. How does MPLS merge traffic flows?

MPLS allows the mapping from IP packet to forwarding equivalence class (FEC) to be performed only once at the ingress to an MPLS domain. A FEC is a set of packets that can be handled equivalently for the purpose of forwarding and thus is suitable for binding to a single label.


From a forwarding point of view, packets within the same subset are treated by the LSR in the same way, even if the packets differ from each other with respect to the information in the network layer header. The mapping between the information carried in the network layer header of the packets and the entries in the forwarding table of the LSR is many to one. That is packets with different content of their network layer headers could be mapped into the same FEC. (example of a FEC: set of unicast packets whose network layer destination address match a particular IP address prefix...)

21. How are loops prevented in MPLS networks?

Before focusing on MPLS loops prevention, let's introduce briefly the different loops handling schemes.

Generally speaking, loop handling can be split into two categories:

Loop prevention: provides methods for avoiding loops before any packets are sent on the path - i.e. Path Vector

Loop mitigation (survival+detection): minimize the negative effects of loopseven though short term transient loops may be formed. - i.e. Time-To-Live (TTL). If the TTL reaches 0, then the packet is discarded

Dynamic routing protocols which converge rapidly to non-looping paths

As far as loop mitigation is concerned, MPLS labeled packets may carry a TTL field that operates just like the IP TTL to enable packets caught in transient loops to be discarded.


However, for certain medium such as ATM and Frame Relay, where TTL is not available, MPLS will use buffer allocation as a form of loop mitigation. It is mainly used on ATM switches which have the ability to limit the amount of switch buffer space that can be consumed by a single VC.

Another technique for non TTL segment is the hop count approach: hop count information is carried within the Link Distribution Protocol messages [3]. It works like a TTL. Hop count will decrease by 1 for every successful label binding.

A third alternative adopted by MPLS is an optional loop detection technique called path vector. A path vector contains a list of the LSRs that label distribution control message has traversed. Each LSR which propagates a control packet (to either create or modify an LSP) adds its own identifier to the path vector list. Loop is detected when an LSR receives a message with a path vector that contains its own identifier. This technique is also used by the BGP routing protocol with its AS path attribute.

22. How does MPLS perform failure recovery?

When a link goes down it is important to reroute all trunks that were routed over this link. Since the path taken by a trunk is determined by the LSR at the start of the MPLS path (head end), rerouting has to be performed by the head end LSR. To perform rerouting, the head end LSR could rely either on the information provided by IGP or by RSVP/CR-LDP.

However, several MPLS-specific resiliency features havebeen developed including Fast Re-Route, RAPID, and Bidirectional Forwarding. See RFC 3469: "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery" for additional information.

23. What differences are there in running MPLS in OSPF versus IS-IS environments?


This is not an MPLS question but an IGP (Interior Gateway Protocol) question. MPLS extensions, stated in IEFT RFC's, are supported for both OSPF and IS-IS. MPLS and BGP-VPN real-world deployments have been on both protocols for some time now.

There is much debate over which IGP is best. This is usually centered around scalability. The street word is that IS-IS is more scaleable than OSPF. That is, a single OSPF area can support 150 plus routers and a single IS-IS area can support 500 plus routers. However, very large IS-IS and OSPF networks have been deployed.

Ultimately, it is best to first understand the benefits and disadvantages of each protocol. Then use the customer / network requirements to choice the IGP which best suites your needs.

24. Can there be two or more Autonomous Systems within the same MPLS domain?

This is possible only under very restricted circumstances. Consider the ASBRs of two adjacent ASes. If either or both ASBRs summarize eBGP routes before distributing them into their IGP, or if there is any other set-up where the IGP routes cover a set of FECs which differs from that of the eBGP routes (and this would almost always be the case), then the ASBRs cannot forward traffic based on the top-level label. A similar argument applies to TE tunnels. Some traffic usually will be either IP forwarded by the ASBR, or forwarded based on a non-top-level label.

So there would usually be 2-3 MPLS forwarding domains if there were two ASes: one for each of the two ASes, and possibly one for the link between the two ASBRs (in the case that labelled packets instead of IP packets are forwarded between the two ASBRs).

Also, it's likely that the ASBRs could not be ATM-LSRs, as ATM-LSRs typically have limited or no capability of manipulating label stacks or forwarding unlabelled IP traffic.

Another example (thanks to Robert Raszuk) is with the multi-provider application of BGP+MPLS VPNs. As described earlier, there are usually no *top-level* LSPs established across the two (or more) provider ASes involved, so it can be argued that:

The two ASes are separate administrative domains. However there are some LSPs established across the two ASes, at a lower level in the label stack. So, it can be argued that


(1) and (2) are both true, which implies that different definitions of the boundary of the administrative domains can exist with respect to different levels in the label stack. It is also (in hindsight) obvious that different MPLS domain boundaries can exist with respect to different levels of the label stack.

MPLS VPNs

25. How does MPLS enable VPNs?

Since MPLS allows for the creation of "virtual circuits" or tunnels, across an IP network, it is logical that service providers would look to use MPLS to provision Virtual Private Network services. Several standards have been proposed to allow service providers to use MPLS to provision VPN services that isolate a customers traffic across the provider's IP network and provide secure end-to-end connectivity for customer sites.

It should be noted that using MPLS for VPNs simply provides traffic isolation, much like an ATM or Frame Relay service. MPLS currently has no mechanism for packet encryption, so if customer requirements included encryption, some other method, such as IPsec, would have to be employed. The best way to think of MPLS VPNs is to consider them the equivalent of a Frame Relay or ATM virtual circuit.

26. What alternatives are there for implementing VPNs over MPLS

There are multiple proposals for using MPLS to provision IP-based VPNs. One proposal (MPLS/BGP VPNs) enabled MPLS-VPNs via extensions to Border Gateway Protocol (BGP). In this approach, BGP propagates VPN-IPv4 information using the BGP multiprotocol extensions (MP-BGP) for handling these extended addresses. It propagates reachability information (VPN-IPv4 addresses) among Edge Label Switch Routers (Provider Edge router). The reachability information for a given VPN is propagated only to other members of that VPN. The BGP multiprotocol extensions identify the valid recipients for VPN routing information. All the members of the VPN learn routes to other members.

Another proposal for using MPLS to create IP-VPN's is based on the idea of maintaining separate routing tables for various virtual private networks and does not involve BGP.

Most implementations of Layer 3 MPLS-VPNs are based on RFC-2547.

27. What is the "Martini Draft'?

The "Martini Draft" actually refers to set of Internet drafts co-authored by Luca Martini. These drafts define how MPLS can be used to support Layer 2 transport services such as Ethernet, Frame Relay and/or ATM. Martini drafts define Layer 2 encapsulation methods, as well as Layer 2 transport signaling methods.

Many service providers wish to use MPLS to provision L2-based services to provide an easy migration for the current L2 service customers, while the providers migrate their networks to MPLS. Service providers can use standards such as Martini Draft to provide a myriad of services over their MPLS networks, so customers can simply choose the technology that is best suited to their environment.


The Psuedo Wire Emulation Edge-to-Edge (PWE3) working group is currently developing standards for Layer 2 encapsulation (including Draft-Martini and other supporting standards). Current working group drafts can be located at www.mplsrc.com/standards.shtml under the sub-heading "Layer 2 VPNs and Layer 2 Emulation."

28. What is a "Layer 2 VPN"

Layer 2 VPNs are an extension of the work being undertaken in the PWE3 working group. Layer 2 VPNs allow service providers to provision Layer 2 services such as Frame Relay, ATM and Ethernet between customer locations over an IP/MPLS backbone. Service providers can thus provision Layer 2 services over their IP networks, removing the need to maintain separate IP and Frame Relay/ATM network infrastructures. This allows service providers to simplify their networks and reduce operating expenses.

The IETF's "Layer 2 Virtual Private Networks (l2vpn)" working group is currently defining standards for provisioning Layer 2 VPN services. Current working group drafts can be located at www.mplsrc.com/standards.shtml under the sub-heading "Layer 2 VPNs and Layer 2 Emulation."

29. What is a Virtual Private LAN Service (VPLS)?

VPLS refers to a method for using MPLS to create virtual LAN services based on Ethernet. In this type of service, all edge devices maintain MAC address tables for all reachable end nodes, much in the same way as a LAN switch.

VPLS services enable enterprises to provide Ethernet reachability across geographic distances served by MPLS services. Several alternatives for enabling VPLS services are in development by the L2VPN working group. Please refer to drafts from that working group for additional information. Also see the Juniper Network's White Paper "VPLS: Scalable Transparent LAN Services."

30. Are MPLS-VPNs secure?

Among many network security professionals, the term "VPN" implies "encrypted" tunnels across a public network. Since MPLS-VPNs do not require encryption, there is often concern over the security implications of using MPLS to tunnel non-encrypted traffic over a public IP network. There are a couple of points to consider in this debate:

MPLS-VPN traffic is isolated by the use of tags, much in the same way ATM and Frame Relay PVCs are kept isolated in a public ATM/Frame Relay network. This implies that security of MPLS-VPNs is equivalent to that of Frame Relay or ATM public network services. Interception of any of these three types of traffic would require access to the service provider network.

MPLS-VPNs do not prohibit security. If security is an issue, traffic can be encrypted before it is encapsulated into MPLS by using a protocol such as IPSec or SSL.

The debate over MPLS security really comes down requirements of the customer. Customers comfortable with carrying their traffic over public ATM or Frame Relay services should have the same level of comfort with MPLS-VPN services. Customers requiring additional security should employ encryption in addition to MPLS.


MPLS Quality of Service

31. What kinds of QoS protocols does MPLS support?

MPLS supports the same QoS capabilities as IP. These mechanisms are IP Precedence, Committed Access Rate (CAR), Random Early Detection (RED), Weighted RED, Weighted Fair Queuing (WFQ), Class-based WFQ, and Priority Queuing. Proprietary and non-standard QoS mechanisms can also be support but are not guaranteed to interoperate with other vendors.

Since MPLS also supports reservation of Layer 2 resources, MPLS can deliver finely grained quality of service, much in the same manner as ATM and Frame Relay.


32. How do I integrate MPLS and DiffServ

DiffServ can support up to 64 classes while the MPLS shim label supports up to 8 classes. This shim header has a 3-bit field defined ãfor experimental use. This poses a problem. This Exp field is only 3 bits long, whereas the Diff-Serv field is 6 bits. There are different scenarios to work around this problem.

There are two alternatives that address this problem called Label-LSP and Exp-LSP models. But they introduce complexity into the architecture. The diffserv model essentially defines the interpretation of the TOS bits. As long as the IP precedence bits map to the Exp bits the same interpretation as the diffserv model can be applied to these bits. In the case where additional bits are used in the diffserv model, one can essentially use the label value to interpret the meaning of the remaining bits. Recognizing that 3 bits are sufficient to identify the required number of classes, the remaining bits in the diffserv model are used for identifying the drop priority and these drop priorities can be mapped into an L-LSP in which case the label identifies the drop priority while the exp bits identify the Class that the packet belongs to.

Many Service Provides have or will add just a few classes. This small enhancement will be hard enough to provision, manage and sell. This would be an effective strategy to get to market quickly with a value-added service.

The followings classes may be more appropriate for the initial deployment of MPLS QoS:

High-priority, low-latency "Premium" class (Gold Service)
Guaranteed-delivery "Mission-Critical" class (Silver Service)
Low-priority "Best-Effort" class (Bronze Service)

33. How do I integrate MPLS and ATM QoS ?

MPLS makes it possible to apply QoS across very large routed or switched networks because Service Providers can designate sets of labels that have special meanings, such as service class. Traditional ATM and Frame Relay networks implement CoS with point-to-point virtual circuits, but this is not scalable for IP networks. Placing traffic flows at the edge into service classes enables providers to engineer and manage classes throughout the network.

If service providers manage networks based on service classes, not point-to-point connections, they can substantially reduce the amount of detail they must track and increase efficiency without losing functionality. Compared to per-circuit management, MPLS-enabled CoS provides virtually all of the benefit with far less complexity. Using MPLS to establish IP CoS has the added benefit of eliminating per-VC configuration. The entire network is easier to provision and engineer.


Generalized MPLS

34. What is "Generalized MPLS" or "GMPLS"

From "Generalized Multi-Protocol Label Switching Architecture" "Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber)."

GMPLS represents a natural extension of MPLS to allow MPLS to be used as the control mechanism for configuring not only packet-based paths, but also paths in non-packet based devices such as optical switches, TDM muxes, and SONET/ADMs.

35. What are the components of GMPLS?

GMPLS introduces a new protocol called the "Link Management Protocol" or LMP. LMP runs between adjacent nodes and is responsible for establishing control channel connectivity as well as failure detection. LMP also verifies connectivity between channels.

Additionally, the IETF's "Common Control and Measurement Plane" working group (ccamp) is working on defining extensions to interior gateway routing protocols such as OSPF and IS-IS to enable them to support GMPLS operation.

36. What are the features of GMPLS?


GMPLS supports several features including:

Link Bundling - the grouping of multiple, independent physical links into a single logical link

Link Hierarchy - the issuing of a suite of labels to support the various requirements of physical and logical devices across a given path

Unnumbered Links - the ability to configure paths without requiring an IP address on every physical or logical interface

Constraint Based Routing - the ability to automatically provision additional bandwidth, or change forwarding behavior based on network conditions such as congestion or demands for additional bandwidth

37. What are the "Peer" and "Overlay" models?

GMPLS supports two methods of operation, peer and overlay. In the peer model, all devices in a given domain share the same control plane. This provides true integration between optical switches and routers. Routers have visibility into the optical topology and routers peer with optical switches. In the overlay model, the optical and routed (IP) layers are separated, with minimal interaction. Think of the overlay model as the equivalent of today's ATM and IP networks, where there is no direct connection between the ATM layer and the IP routing layer.

The peer model is inherently simpler and more scalable, but the overlay model provides fault isolation and separate control mechanisms for the physical and routed network layers, which may be more attractive to some network operators.

38. What is the "Optical Internetworking Forum"?

The Optical Internetworking Forum (OIF) is an open industry organization of equipment manufacturers, telecom service providers and end users dedicated to promote the global development of optical internetworking products and foster the development and deployment of interoperable products and services for data switching and routing using optical networking technologies.

An Introduction to the Optical Internetworking Forum White Paper can be found at http://www.oiforum.com/

Voice over MPLS

39. Can voice and video traffic be natively encapsulated into MPLS?

Yes. The MFA Alliance has released a bearer transport implementation agreement which can be viewed at http://www.mfaforum.org/VoMPLS_IA.pdf.

MPLS Management

40. How are MPLS networks managed?

Currently, most MPLS implementations are managed using CLI. Tools such as WANDL's NPAT simulator allow MPLS networks to be modeled prior to deployment.

Several companies in the operational support systems product space have introduced tools designed to ease MPLS network management and automatically provision LSPs.

41. Are there any MPLS-specific MIBs?

Yes. Several internet drafts have proposed creating MPLS-specific MIBS.

42. Is there open source MPLS code to test MPLS?

Yes. Several open source implementations of MPLS currently exist.


MPLS Training

43. What shows and conferences provide information on MPLS?

Several conferences are devoted to, or include presentations on MPLS. These include:

"MPLScon" held each May in New York City
"MPLS World Congress" held each February in Paris
"MPLS 200x" held each fall in Washington D.C.

MPLS Interoperability Testing

44. Are there any labs that are performing MPLS interoperability testing?

Several groups and organizations conduct MPLS interoperability testing, including:

The University of New Hampshire Interoperability Lab has set up a MPLS Consortium for vendors to test the interoperability of their products and to support MPLS standards development. More information is available on their web site at http://www.iol.unh.edu/consortiums/mplsServices/.

Isocore in Fairfax, VA conducts interoperability testing and hosts the "MPLS 200x" annual event each fall in Washington D.C.

The MFA Forum has conducted several GMPLS interoperability testing events at conferences such as SuperComm and Next Generation Networks.

EANTC AG is a vendor-neutral network test center located in Berlin, Germany and conducts independent MPLS interoperability testing

Photonic Internet Lab is supported by the Government of Japan and provides testing and simulation efforts for GMPLS development.

10 comments:

  1. Good document !

    ReplyDelete
  2. So helpful and a great document.

    ReplyDelete
  3. it's very helpfull thank you

    ReplyDelete
  4. Hello there! I could have sworn I've been to this blog before but after checking
    through some of the post I realized it's new to me.

    Anyways, I'm definitely happy I found it and I'll be bookmarking and checking back frequently!


    Here is my web site ... we r movers South Carolina

    ReplyDelete
  5. Tks very much for your post.

    Avoid surprises — interviews need preparation. Some questions come up time and time again — usually about you, your experience and the job itself. We've gathered together the most common questions so you can get your preparation off to a flying start.

    You also find all interview questions at link at the end of this post.

    Source: Top 10 interview questions and answers

    Best rgs

    ReplyDelete
  6. You have posted some really great stuff here. I really like your comments regarding my problems or I must say that you have proposed a solutions to a universal problem. Kudos to you, and good luck for your future blogs.
    For more information visit our website: www.gravityusa.com

    ReplyDelete
  7. Hi everyone very good alps guides us for jobs and there set mind set to judge us

    ReplyDelete

My Blog List

Networking Domain Jobs