Performance Issues in VC-Merge Capable ATM LSRs
RFC 2682

Document Type RFC - Informational (September 1999; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2682 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         I. Widjaja
Request For Comments: 2682                Fujitsu Network Communications
Category: Informational                                       A. Elwalid
                                          Bell Labs, Lucent Technologies
                                                          September 1999

            Performance Issues in VC-Merge Capable ATM LSRs

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   VC merging allows many routes to be mapped to the same VC label,
   thereby providing a scalable mapping method that can support
   thousands of edge routers. VC merging requires reassembly buffers so
   that cells belonging to different packets intended for the same
   destination do not interleave with each other.  This document
   investigates the impact of VC merging on the additional buffer
   required for the reassembly buffers and other buffers.  The main
   result indicates that VC merging incurs a minimal overhead compared
   to non-VC merging in terms of additional buffering. Moreover, the
   overhead decreases as utilization increases, or as the traffic
   becomes more bursty.

1.0 Introduction

   Recently some radical proposals to overhaul the legacy router
   architectures have been presented by several organizations, notably
   the Ipsilon's IP switching [1], Cisco's Tag switching [2], Toshiba's
   CSR [3], IBM's ARIS [4], and IETF's MPLS [5].  Although the details
   of their implementations vary, there is one fundamental concept that
   is shared by all these proposals: map the route information to short
   fixed-length labels so that next-hop routers can be determined by
   direct indexing.

   Although any layer 2 switching mechanism can in principle be applied,
   the use of ATM switches in the backbone network is believed to be a
   very attractive solution since ATM hardware switches have been
   extensively studied and are widely available in many different

Widjaja & Elwalid            Informational                      [Page 1]
RFC 2682          Issues in VC Merge Capable ATM LSRs     September 1999

   architectures.  In this document, we will assume that layer 2
   switching uses ATM technology. In this case, each IP packet may be
   segmented to multiple 53-byte cells before being switched.
   Traditionally, AAL 5 has been used as the encapsulation method in
   data communications since it is simple, efficient, and has a powerful
   error detection mechanism.  For the ATM switch to forward incoming
   cells to the correct outputs, the IP route information needs to be
   mapped to ATM labels which are kept in the VPI or/and VCI fields.
   The relevant route information that is stored semi-permanently in the
   IP routing table contains the tuple (destination, next-hop router).
   The route information changes when the network state changes and this
   typically occurs slowly, except during transient cases.  The word
   "destination" typically refers to the destination network (or CIDR
   prefix), but can be readily generalized to (destination network,
   QoS), (destination host, QoS), or many other granularities. In this
   document, the destination can mean any of the above or other possible
   granularities.

   Several methods of mapping the route information to ATM labels exist.
   In the simplest form, each source-destination pair is mapped to a
   unique VC value at a switch. This method, called the non-VC merging
   case, allows the receiver to easily reassemble cells into respective
   packets since the VC values can be used to distinguish the senders.
   However, if there are n sources and destinations, each switch is
   potentially required to manage O(n^2) VC labels for full-meshed
   connectivity.  For example, if there are 1,000 sources/destinations,
   then the size of the VC routing table is on the order of 1,000,000
   entries.  Clearly, this method is not scalable to large networks.  In
   the second method called  VP merging, the VP labels of cells that are
   intended for the same destination would be translated to the same
   outgoing VP value, thereby reducing VP consumption downstream.  For
   each VP, the VC value is used to identify the sender so that the
   receiver can reconstruct packets even though cells from different
   packets are allowed to interleave.  Each switch is now required to
   manage O(n) VP labels - a considerable saving from O(n^2).  Although
   the number of label entries is considerably reduced, VP merging  is
   limited to only 4,096 entries at the network-to-network interface.
   Moreover, VP merging requires coordination of the VC values for a
   given VP, which introduces more complexity.  A third method, called
   VC merging, maps incoming VC labels for the same destination to the
Show full document text