6/98 Netwatcher "In the Know" on MPLS and ATM
datacomm-us.com
Many technology advancements are driven by vendors who want to change the status quo. In the IP space,
there is no more eager group than the ATM vendors, whose dreams of gigabucks arising from wholesale
conversion of networking to ATM have been dashed in the late 1990s. In this last of our MPLS features, we're going to examine how MPLS relates to virtual circuit technology in general, and to ATM in particular.
Labels and VCs: Two Options
One of the properties of label-linked MPLS routes is that they can be readily mapped to virtual circuits. In fact,
that capability may prove to be one of the most important aspects of MPLS design.
There are two models one could presume for MPLS in a virtual circuit environment. One model says that the
virtual circuit network appears as a kind of "MPLS black box" that exhibits MPLS properties at the edge, but
not necessarily internally. The other is the more formalized MPLS model, in which virtual circuit devices exhibit
uniform MPLS properties throughout the network.
The black box model of MPLS is the most generalized for vendors and users, but provides less assurance of
multi-vendor interoperability. In this model, a network of virtual circuit devices is created using whatever topology and routing architecture the vendor finds convenient. At the edge, the network presents an MPLS interface and responds to MPLS LDP messages and labeled packets as though the network were a distributed
MPLS node. The network may (and probably will) also present router functionality at the edge, accepting and generating topology updates using a protocol like RIP or OSPF. The "view" of itself it
presents to those
protocols is that of a single, multi-connected, device.
The formalized MPLS model of virtual circuit networking with MPLS requires that the virtual circuit nodes be
MPLS-capable, and also be routing-capable to the extent that some model of route determination must be
developed to provide steering of the LDP messages that create the label-linked routes.
Since it is unlikely that the route-threading process will span only the virtual circuit portion of the network, it is
likely that the route determination architecture of the virtual circuit network would have to be the same as that of the rest of the MPLS network.
Black-box MPLS, because it is based on ATM networking inside the vendor's cloud of devices, tends to retain
a lot of connection-oriented properties. Both Ascend and Nortel, who have VPN-over-ATM strategies that could be (at least in Ascend's case) mapped to MPLS, create a kind of IP layer around a virtual circuit network core. This makes their VPNs behave like frame relay networks with router features added (which happens to be how buyers want VPNs to behave).
Formalized MPLS networks, because they make each ATM node behave like a router, tend to create VPNs that
look more like router VPNs. We must note that this tendency isn't institutionalized in the design, just preferenced in the orientation.
Black Box Virtual Circuits
In the black box virtual circuit model of MPLS, the first step is to establish the virtual circuit network as a virtual router for those protocols that MPLS will explicitly use (for LDP threading of routes, for example, or for
reconnect or route gateway functions). We've talked about MPLS topology management and routing before,
so all we need say here is that something has to route the "MPLS-equivalent virtual circuits" inside the black
box of the network. It can be MPLS-related (as Ascend's IP Navigator), totally ATM-centric (PNNI) or something in between.
Whatever the strategy for route management and route determination, the process of threading an MPLS route through a black box implementation would be similar:
1.The LDP message would arrive at the black box edge node as a normal LDP message. If there is a route
stack associated with it, a black box network would appear as a single node/entry in that stack.
2.The edge node would pop its entry off the stack (if necessary) and determine the edge node at which it
supports the thread's next hop, either through stack processing or through address lookup.
3.The edge node would invoke an internal route threading (set up a virtual circuit) to that
destination point, and forward the LDP message over it to that point. The internal identifier of this
VC would be equated to the incoming label in a table at the source edge node, and to the destination label at the exit node, connecting the internal route thread to the external flow.
4.The exit edge point would emit the LDP message to its correct MPLS neighbor, using the exit label.
The only place where there's variability of function here is the middle. How the edge
node knows the reachability of its neighbors is dependent on the topology approach taken in the black box network. Likewise, how the virtual circuit is set up and threaded depends on the connection and routing architecture of the black box network.
Processing a labeled packet is straightforward once a route has been established:
1.The labeled packet arrives at an MPLS source edge node, bearing an incoming label.
2.The source edge node would look the incoming label up in its table to identify the virtual circuit to which the label-linked route is associated.
3.The labeled packet would be shunted onto the indicated virtual circuit to the exit edge node.
4.At the exit edge node, the incoming label would be looked up on the exit label table. It would then be replaced by the exit label, and the packet forwarded according to MPLS exit rules.
Note that in this model, there is no structural linkage between a virtual circuit ID and an MPLS route label. The correlation is maintained in the edge nodes of the black box network. There is also no requirement that any discipline in particular be used to create the virtual circuit. This contrasts with the next option, the formalized MPLS integration with virtual circuit networks.
In general, we expect switch vendors to adopt a "black box" MPLS model. This is due in part to the fact that most will have routing and topology management functions already in place, designed for
virtual circuit routing. Often these will provide better QoS-based routing than could be obtained by using a per-node MPLS
formalism based on IP metrics. Another factor is the likelihood that switch vendors would want to differentiate
themselves based on MPLS support features, something difficult to do if everyone slavishly adopts the same
set of standards. Finally, switches (unlike routers) are not popularly expected to be box-by-box interoperable with one another; no X.25, frame, or ATM products are today, and no standards exist for interoperation at this level.
Virtual Circuit Threading With Formal MPLS
MPLS documents indicate that the VC ID of frame relay or ATM can be used as a label. This means that the
MPLS procedures operate in every frame/cell node in parallel with or in place of standard frame/cell routing
procedures. The process of call setup is displaced by the process of label-linked route setup, and the process of VC switching becomes the process of label switching.
To make this process work, the ATM or frame switch must first "watch" a particular VC for administrative
traffic. This channel would be used to propagate the LDP message sets, to eliminate the need for the switch to
examine the contents of transit label-linked routes.
An LDP threading process would have to work pretty much the same here as for an individual MPLS node.
The "label", however, would be the VPI/VCI or DLCI of the frame or cell, so there would be no need to prepend an encapsulation header to contain it.
It is highly doubtful that virtual circuit identification based on globally significant VC identifiers would be
useful with MPLS, given the fact that the number of label-linked routes that could be expected in a network
could be massive. The next question would be whether the VCID would have to be node-significant, or could be assigned on a port basis.
As far as can be determined based on current documents, MPLS expects labels to be unique for a given node, though this assumption doesn't appear to be rooted in any specific requirement. Thus, it would appear that there are two ways the VCID could be handled:
1.An MPLS VC device could assign labels globally, meaning that the VCID address space would have to contain the total number of routes that pass through the node. This might be practical with ATM, which has a larger address space, but is not likely to work with frame relay, which is limited to less than a thousand VCIDs.
2.An MPLS VC device could assign a label exactly as it assigns a VCID now, meaning within a port. This would mean that the source port number would have to be concatenated with the VCID to create a unique label for lookup on a common label table, or that the label table would have to be maintained by port.
Logic seems to favor the latter approach, but it isn't completely clear whether abandoning the concept of a
node-unique label is completely safe. Certainly, a label assigned by node/trunk more closely follows virtual
circuit assignment practices today, and would likely be more compatible with current equipment design as a result.
Some Special Issues for VC-Mapped MPLS
Three issues appear to arise in any implementation of MPLS integrated with virtual circuit devices:
How will the implementation handle VC merge procedures?
How will the implementation handle multicast?
Will the implementation support "default routing", meaning the handling of packets through normal routing table functions, not MPLS label switch procedures?
VC merge is a challenge for any ATM-based MPLS implementation because the normal model of ATM data
encapsulation (AAL5) doesn't support merging the cell streams of two unlike information sources and
recovering the original packets intact. It lacks a message/cell sequence number, for one thing, and for another, such a number would be useful only if we could assume that disparate sources could be expected to come up with message numbers that would be unique.
We should note that there is no necessary connection between VC merge and frame relay or ATM. In theory,
any MPLS node could offer VC merge, but since the only thing that would be conserved in a non-frame/cell
device is the number of labels, it isn't clear whether there is any benefit. The MPLS spec does call for VC merge in a generic sense, however, and most MPLS devices will probably offer it.
An alternative to a packet black box for VC merge in ATM networks is the use of virtual paths to aggregate
routes. In this approach, a node sources a VP to each destination node. When label-linked routes merge at a
node, the VCs are merged onto the VP that is associated with the destination. This process can create problems if the number of destination nodes are high, however.
Packet-merge black boxes may be necessary in any case. As it happens, the issue of multicasting also creates a
potential packet-handling requirement. If MPLS is to support multicasting, it must replicate packets at each
fork in the multicast tree, putting a copy on each outbound path. This could be done through normal VC
point-to-multipoint procedures, but special management of the trees would be required.
The last issue, the handling of packets using standard Level 3 procedures, may also
argue for packet-aware
components in virtual circuit devices. That label route threading may be dependent on IP routing tables is a truth previously noted. It is also true that IP routing will be required to link an MPLS fabric of routes to a connectionless DMARK supporting a non-MPLS end user. Finally, it is likely that best-efforts IP services would be provided using standard IP routing even in a network with MPLS support
available throughout.
As we've noted before, packet awareness in the last sense covered here could be provided either by making
each node MPLS-packet-IP aware, or by creating a black box network that appeared as a virtual MPLS node.
The other strategies, however, would require some explicit packet awareness in each ATM or frame relay node in order to be supported effectively. In the balance, we believe it is safe to assume that some form of IP awareness will be added to all frame/cell networks, and that a portion of this will probably be distributed to
each node.
Conclusion
Nothing reflects the schism in MPLS viewpoint as much as the relationship between MPLS and ATM. Many will criticize vendors like Ascend who elect the black box strategy-"non-standard" is a label the press loves to apply to things-but there is good reason for ATM players to take this route. The IETF appears determined to promote the traffic management view of MPLS, and that view would compromise the service value-add that MPLS could bring. Since that service value-add is the key value proposition for adding ATM to IP networks, ATM vendors can't afford to let router-heads take it away.
The battle for the hearts and minds of the marketplace will start here, with the ATM/MPLS boundary. New players will find this the most attractive place to launch products, and older players will find it the border of their kingdom and thus the frontier to be defended.
Nobody's doing a great job of offense or defense yet, but we expect to see some changes over the summer, and certainly by the fall trade show cycle. |
