MPLS’s Label Stacking feature can be used to create a level of hierarchy in large networks that lends itself to highly scalable and efficient traffic flows. For example consider service provider networks running Interior and Exterior routing protocols - say, IS IS and BGP. The BGP label is used to forward packets from a BGP node to another BGP, while the IS IS label is used to forward packets within an AS.

Label stacking can also be very useful for traffic aggregation - an enterprise can aggregate internal traffic flows and feed it into its service provider. The service provider in turn can aggregate traffic from its subscriber enterprises and hand it to a backbone provider.

The operations associated with label stacking are designed to keep in mind the overall architecture of MPLS - i.e. keep the Control and the Forwarding components separate. The stack bit of an MPLS Label (shown as “S” in Figure 1) is used to indicate that the bottom of a stack is reached. When a packet arrives at a transit LSR, the inbound label is looked up against the Incoming Label Map (ILM) to determine the operation to be performed on the top label. If operation of the top label is “Pop” and the Label Stack depth is greater than 1 , then ILM lookup is required for the next label. This process is recursive and continues till the operation on the label is “Swap” or “Bottom of Stack”. Whether the operation is pop or swap can only be determined if the labels are unique over the different levels of the label stack. Labels at different levels of the label stack only need to be in different label spaces if you need to re-use labels at different levels. If not, then you can choose to use the same label space for labels at different level.

It is worthwhile to remember that not all seemingly ideal situations demand label stacking.

For example, consider Figure 2. LSR A is the ingress and penultimate hop for LSR B. LSR B is the egress for FEC 1. LSRs A and B are connected via a tunnel which traverses LSRs X, Y, and Z. When LSR A receives a labeled packet for FEC-1, it can pop the label for FEC-1 and then push the label for the tunnel from A to B. B would then receive a labeled packet with only the tunnel label on it.

The maximum label stack depth is determined by the MTU size of the network, or by the specific application’s minimum usable payload.

Since an LSR does not examine the IP header, the TTL field of the IP header is included in the top label to support the TTL function. There is no significance to the value of the TTL field in any label stack entry that is not at the top of the stack. When labels are popped, TTL values from the popped label are copied on to the top label stack entry for the outgoing MPLS packet.

Implementation of RSVP-TE’s L3PID (defined in the LABEL_REQUEST object) is causing some stress in the industry, as was apparent from a spurt of recent postings on the IETF’s MPLS WG mailing list recently.

The role of the L3PID is for an LSR popping the last MPLS label to know what to do with the packet. A predominant number of implementations follow LDP guidelines and work on the assumption that all packets are IP. Anything that is not IP has a second protocol- identifying label on the stack before being put into an RSVP-TE tunnel.

The de facto standard interpretation has been to manipulate the L3PID to only apply to packets with a label stack of 1. All other packets on the LSP with label stack greater than 1 are simply of “unknown” protocol type.

While a new object has been defined to indicate the presence of a non-L3 payload (G-PID), it is usable for L1 and L2 payloads only.

Even if the L3 protocol is assumed to be IP, the issue regarding distinguishing IPv4 from IPv6 remains an unresolved one. One suggestion is for the LSR popping the last label to check the first bit of the underlying IP header and use it to determine whether the packet is IPv4 or IPv6. When used in conjunction with PHP, this would mean that the penultimate node would need to “look into” the IP header—a functional requirement not defined in any standards thus far. Any implementation that is compliant with the existing specifications therefore cannot be relied upon to perform this option when a single LSP carries both IPv4 and IPv6, and PHP is used.

Another suggested solution is to use different LSPs for IPV4 and IPV6, though use of separate tunnels always raises scalability concerns.

The Internet traffic is relentlessly growing even in these challenging economic times. The service providers and carriers are vigorously evaluating their business models as well as their network and service architectures. While there are still considerable opportunities for vendors with products which match the service providers’ needs, many organizations are in the process of defining their requirements and are preparing to deploy new features and capabilities in their evolving networks.

The Internet Engineering Task Force (IETF) and relevant standardization bodies are specifying new architectures, protocols and techniques which provide the service providers with a multiplicity of options to transition to new generation networks. With the recent consolidation or failure of several service providers, this industry has begun to experience the reality that merely a few instances of the deployments for the standardized features will not warrant a sustainable acceptance. Moreover, unilaterally adopting a technology or particular feature and promoting it to become a standard will not be in the long term interest of this industry.

There has to be a solid and broad support from the carrier and service provider community in harmony with the vendors to launch reasonably long lasting and successful technologies. For this to happen, the intellectual resources in development cycle from the vendor community have to be matched against the future requirements of the carriers and service providers and vice versa.

The present state of the service providers and carriers on one hand, coupled with the failure in the vendor community’s mergers and acquisitions of the last two years, whether due to poor business models or erosion of the market demand, have given rise, more than ever, to the need for cooperation between the service providers and the vendor community. At the end, this will prove to serve everyone best, moving the industry forward and helping revitalize the economy.

In research conducted by the Internet Software Consortium during 2001, the Internet was growing at an astounding rate of 20 million hosts per year. Compare this to the growth rate of the number of hosts on the Internet since 2000, and the results may surprise you. Statistics show that since 2000, approximately 30 million hosts are added to the Internet per year. In addition, there seems to have been a spike in new hosts since early 2002, with an average growth rate of nearly 10 million hosts per month.

According to a study released by the U.S. Department of Commerce in October 2001, the share of households with Internet access was at 41.5%. This still leaves a large room for growth in North America alone.

(Raw Data Source: www.netsizer.com)

The 53rd IETF Meeting was held in Minneapolis, Minnesota, USA from March 17 through March 22,2002. The IETF Sub-IP Area’s MPLS Working Group reported progress during the week, specifically in the area of Fast Reroute. The WG adopted many drafts as WG documents, including drafts for Detecting Data Plane Failures in MPLS (draft-ietf-mpls-lsp-ping-00), Fast Reroute Extensions to RSVP-TE for LSP Tunnels (draft-ietf-mpls-rsvp-lsp-fastreroute-00), and MIB definitions for Fast Reroute (draft-cetin-mpls-fastreroute-mib-00). There were several documents that deferred for acceptance into the WG. The work on Backup RRO for Fast Reroute (draft-decnodder-mpls-ero-rro-fastreroute-00) was kept on the experimental track as was the draft for Optimized Online Placement of MPLS Bypass Tunnels (draft-leroux-mpls-bypass-placement-00). The presentation by Scott Bradner on the impact of ITU’s MPLS OAM standard (Y.1711) sparked discussions that were more than a little heated at times. It was suggested that the ITU standard would require IETF protocols to potentially be modified. Impacted work included specifications on LDP, CR-LDP, RSVP, PIM and BGP.

A tentative consensus was reached to ask ITU for clarifications on their plan in order to better gauge the impact of the ITU standard on work being done by the WG on related protocols.

The Internetworking Laboratory at Isocore recently successfully completed its first round of Leading Edge Code Testing for 2002. Capabilities of Draft Martini encapsulation and Draft Martini transport were extensively tested.

The MPLS core network consisted of POS, Gigabit Ethernet, and ATM links running LDP and RSVP-TE between Avici Systems’ TSR, Cisco Systems’ GSR, Lucent’s Springtide 7000, Marconi’s ASX-4000, and Ericsson’s AXI-540. The IGP used in the network was OSPF. VC tunnel setup capabilities for Layer 2 transport, as specified in the IETF draft “draft-martini-l2circuit-trans-mpls”, were tested for the Cisco 7200, Cisco 7600, Extreme Blackdiamond 6808, Unisphere ERX-700, IXIA 400, Agilent RouterTester, and GNNetTest InterEmulator. Layer 2 encapsulation capabilities as specified by the IETF draft “draft-martini-l2circuit-encap-mpls-04” were tested for Cisco 7200, Cisco 7600, Extreme Blackdiamond 6808, IXIA 400, and Spirent AX4000 BTS. For encapsulation and transport testing, Layer 2 traffic comprised of PPP, AAL5, and VLAN traffic.

This round of testing was the latest in several MPLS interoperability tests pioneered by the Internetworking Lab. In the past, sponsors of the lab have conducted interoperability tests on a variety of topics including MPLS based VPNs (RFC 2547), MPLS Basics-LDP, MPLS Traffic Engineering over MPLS (CR-LDP), Extensions to IS-IS, Extensions to OSPF, ATM-LSRs, MPLS-BGP4, Traffic Engineering over MPLS, and Basic Functionality of Signaling Protocols.

Coming to Washington D.C. in October is the 5th Annual International Conference on MPLS. Hosted jointly by Worldcom and Isocore; and supported by Cable and Wireless, NTT, and France Telecom, this conference will be held at the Omni Shoreham Hotel from October 27 through October 29.

The 3-day conference is co-chaired by Dr. David McDysan of WorldCom, and David Garbin of Cable and Wireless. Marco Carugi of France Telecom, and Dr. Naoki Yamanaka of NTT Japan are the technical co-chairs.

The conference will be followed by the 3rd MPLS Public Interoperability Demonstration at the Internetworking Lab of Isocore.

For details on sponsorship and registration, visit: www.mpls2002.com

I would like to welcome you all to the inaugural issue of Isonotes, a quarterly newsletter released by the Internetworking Lab at Isocore. This publication is envisioned to be a forum for highlighting interoperability developments in the area of MPLS/GMPLS.

I would also like to take this opportunity to encourage you to submit to us brief articles that would be of interest to the GMPLS/MPLS internetworking community.

Isonotes subscribers will be kept informed about planned activities at the Internetworking lab at Isocore as well as Industry and IETF developments.

For starters, Isocore successfully hosted the all-sponsor TAC meet at its McLean office on Monday March 25th. Representatives from 17 vendors and ISPs attended. Sponsors of the Isocore Internetworking lab gained critical insight into requirements from the carrier perspective. The features to be tested during the second round of leading edge code testing will be finalized during the Sponsor TAC meeting in June later this year.

We look forward to meeting many of you during our meetings and the upcoming MPLS2002 conference.

- Kavita Khanna