Omni product guide

7/30/2019 Omni product guide

1/33

LARGESCALE LAN EMULATION NETWORKS

Document Number TR 29.2346

Cedell Alexandera

Matt Squirea

Rustom Masalawalab

Seyhan Civanlarb

aInternational Business Machines Corporation

Research Triangle Park, N.C.

bAT&T

Holmdel, NJ

January 1998


2/33

ii


3/33

iii

ABSTRACT

The ATM Forums LAN Emulation (LANE) Specification has now been available for more than two

years, and LANE products have matured sufficiently that enterprises have deployed production

LAN Emulation networks. However, the scaleability of LANE is still frequently debated, as is its

applicability in WideArea Networks (WANs). This paper examines design features and supporting

applications that can enhance the scaleability and manageability of LAN Emulation networks. The

design features include techniques for distributing the LANE Services to provide load balancing and

robustness, mechanisms for managing broadcast and multicast traffic (which have been a classical

problem with large LAN networks), approaches for controlling signalling rates during powerup

and failover situations, and extensions that exploit the distributed routing capabilities provided by

the Next Hop Resolution Protocol (NHRP). Issues associated with WAN deployment of LAN

Emulation are also explored, including requirements for carrierbased service environments, where

conservation of network resources, security capabilities, and monitoring applications are especially

important. The paper is concluded with an assessment of LANEs status/prospects as a technology

for building largescale networks.

ITIRC KEYWORDS

Local Area Networks (LAN)

Wide Area Networks (WAN)

Asynchronous Transfer Mode (ATM)

LAN Emulation (LANE)

Emulated LANs (ELAN)

ATM Forum

Broadcast Management

Next Hop Resolution Protocol (NHRP)


4/33

iv


5/33

v

ABOUT THE AUTHORS

Cedell Alexander is a Senior Engineer in IBMs Networking Division who is currently workingon MPOA development for IBMs Multiprotocol Switched Services (MSS) products. He was the

chiefarchitect for Release 1.1 of the MSS Server, and led the LAN Emulation Service development

team for Release 1.0 ofthe MSS Server. Cedell has 17+ years of industry experience, has authored

44 technical publications along with 13 patent applications, and is a contributing member of the

ATM Forums LAN Emulation/MPOA SubWorking Group. He received BS and MS degrees in

Electrical Engineering from the University of Houston, and a PhD in Computer Engineering from

Mississippi State University. Cedell may be reached by telephone at 9192542106, or via the

Internet at [email protected].

Matt Squire is an Advisory Engineer in IBMs Networking Division who is currently leading the

LAN Emulation development team for IBMs Multiprotocol Switched Services (MSS) products.

Matt developed the LAN Emulation Configuration Server for Release 1.0 of the MSS Server , and

is a contributing member of the ATM Forums LAN Emulation/MPOA SubWorking Group. He

received a PhD in Computer Science from North Carolina State University in 1995, and his research

has lead to several publications. Matt may be reached by telephone at 9192548183, or via the

Internet at [email protected].

Rustom Masalawala is employed by AT&T in Holmdel NJ and is a contributing member of the

ATM Forums LAN Emulation/MPOA SubWorking Group. Rustom may be reached by telephone

at 9089497348, or via the Internet at [email protected].

Seyhan Civanlar is employed by AT&T in Holmdel NJ and is a contributing member of the ATM

Forums LAN Emulation/MPOA SubWorking Group. Rustom may be reached by telephone at

9089490969, or via the Internet at [email protected].


6/33

vi


7/33

vii

CONTENTS

ABSTRACT iii

ITIRC KEYWORDS iii. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ABOUT THE AUTHORS v

LIST OF ILLUSTRATIONS ix

ACKNOWLEDGMENTS xi

1. INTRODUCTION 1

2. OVERVIEW OF LAN EMULATION 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. SCALEABILITYENHANCING DESIGN FEATURES 5. . . . . . . . . . . . . . . . . . . . . . .3. 1. DISTRIBUTED LANE SERVICES 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. 2. BROADCAST MANAGEMENT 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. 3. MANAGING IP MULTICAST TRAFFIC 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. 4. CONTROLLING SIGNALLING RATES 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. 5. DISTRIBUTED ROUTING 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. WAN DEPLOYMENT ISSUES 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. 1. SECURITY ISSUES 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. 2. MONITORING ISSUES 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. CONCLUSION 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

REFERENCES 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


8/33

viii


9/33

ix

LIST OF ILLUSTRATIONS

Figure 1. Physical and Logical Views of a Simple LAN Emulation Network 4. . . . . . . . . .

Figure 2. Distributing the LANE Services with Shortcut Bridging 7. . . . . . . . . . . . . . . . . . .

Figure 3. Managing Broadcasts at the BUS 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 4. Managing Broadcasts at the Shortcut Bridge 9. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 5. Managing IP Multicasts with Dedicated ELANs 10. . . . . . . . . . . . . . . . . . . . . . . . .

Figure 6. OneHop Routing in a LANE Environment 13. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 7. ZeroHop Routing with Route Switching 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 8. WAN Configuration with Single LES/BUS Architecture 15. . . . . . . . . . . . . . . . . .

Figure 9. WAN Configuration with Distributed LES/BUS Architecture 16. . . . . . . . . . . . . . .

Figure 10. WAN Configuration with Distributed LES/BUS and COBased Services 16. . . . .


10/33

x


11/33

xi

ACKNOWLEDGMENTS

The IBM authors thank our manager, Rick Matlack, for his support, and acknowledge the

contributions of the entire Multiprotocol Switched Services development team, whose long hours

of work have made concepts described in this paper a reality.


12/33

xii


13/33

1

1. INTRODUCTION

The size ofLocal Area Networks (LANs) has traditionally been limited by two primary factors:

physical link characteristics and broadcast traffic. A single physical link (e.g., an Ethernet or

TokenRing LAN segment) supports a limited number of stations, offers limited geographical

coverage, and provides limited bandwidth. One way to extend these physical limitations is to bridge

LAN segments together. For some protocols, such as IBMs Systems Network Architecture (SNA),

bridging has been very effective, but for other protocols, like IP, the scaleability of bridged networks

is constrained by the volume of broadcast traffic. Consequently,routers have often been employed

to limit broadcast domains. While routers can solve this problem, they introduce complications of

their own, such as administrative overhead, increased latency, and potential throughput bottlenecks

that are compounded by a price/performance ratio that tends to increase with router performance.

Asynchronous Transfer Mode (ATM) technology, coupled with theLAN Emulation (LANE) standard

developed by theATM Forum [1], provide the foundation for a costeffective alternative solution

based on simple, highspeed hardware switching mechanisms.

ATM was designed to be a universal networking technology and its benefits have been

wellchronicled: lowcost hardware that supports scaleable networks composed of

highbandwidth, lowlatency links with Quality of Service (QoS) guarantees. These characteristics

make ATM appropriate for both Local and Wide Area Networks (WANs) that support a variety of

different applications including voice, data, and multimedia traffic. Hardware switching is one of

the fundamental components that enables ATM to offer these features, and the advantages of

hardware switching have also been widely realized in traditional LAN environments. Together,

ATM and LAN switching provide the building blocks for a highperformance networking

infrastructure supporting current and future needs. The ATM Forums LAN Emulation

Specification integrates these components in a manner enabling multivendor interoperability.

LAN Emulation protocols allow ATM networks to provide the appearance of Ethernet andTokenRing Local Area Networks. Although LAN Emulation does not exploit all of ATMs

capabilities, it is useful in migrating to ATM technology and lowering network management costs.

Highspeed ATM links can be utilized while still protecting software and hardware investments.

Software investments are protected because application interfaces are unchanged, and hardware

investments are protected by LAN Switches that bridge traditional LANs and Emulated LANs

(ELANs), allowing continued utilization of existing adapters/wiring. LAN Emulation also enables


14/33

2

an incremental migration strategy where ATM adapters are gradually installed in stations requiring

additional bandwidth (e.g., servers and engineering/multimedia workstations).

The network management benefits of ELANs come from increased configuration flexibility.

Membership in an Emulated LAN is not based on physical location; instead, logicallyrelated

stations are grouped to form an ELAN. As long as ELAN memberships are retained, no

reconfiguration is needed when stations move to new physical locations. Similarly, no wiring

modifications are needed to move stations from one ELAN to another.

When augmented with the design features and supporting applications described in this paper, the

advantages of LAN Emulation can be extended to largescale enterprise networks. A brief

overview of LAN Emulation basics is provided in Section 2. as a preface to the discussion of

enhancements which improve the scaleability of LANE in Section 3. Topics covered in Section3. include techniques for distributing the LANE Services, mechanisms for managing broadcast and

multicast traffic, approaches for controlling signalling rates, and extensions that exploit the

capabilities provided by the Next Hop Resolution Protocol (NHRP). Issues associated with WAN

deployment of LAN Emulation are examined in Section 4. with a focus on requirements for

carrierbased service environments, where conservation of network resources, security capabilities,

and monitoring applications are particularly important. The paper is then concluded in Section

5. with an assessment of LANEs status/prospects as a technology for building largescale networks.


15/33

3

2. OVERVIEW OF LAN EMULATION

The components that implement an ELAN are LAN Emulation Clients (LECs), the LAN Emulation

Configuration Server (LECS), the LAN Emulation Server (LES), and the Broadcast and Unknown

Server (BUS). The LES, BUS, and LECS are collectively referred to as the LE Service components.

Each ELAN has a dedicated LES and BUS (but a single hardware platform can provide LE Services

for multiple ELANs). LECs reside in end systems (e.g., ATMattached hosts or LAN switches

representing hosts residing on traditional LAN segments) and provide a Media Access Control

(MAC)level service to higherlayer software. To emulate a LAN, LECs request services from the

LECS, LES, and BUS.

The LECS reduces the network management burden by serving as a centralized repository for

configuration data, minimizing configuration at LECs. The LECS helps create aplugandplay

environment by providing initial configuration data to LECs, with the most crucial piece of data

being the ATM address of the LES. LECs connect to the LECS using welldefined procedures that

include obtaining the address of the LECS from the ATM switch or use of a WellKnown LECS

ATM Address.

After receiving the ATM address of the LES, the LEC begins to join the ELAN by setting up a

Control Direct Virtual Channel Connection (VCC) to the LES and sending anLE_JOIN_REQUEST. The LES typically responds by adding the LEC to a pointtomultipoint

Control Distribute VCC and returning a successful LE_JOIN_RESPONSE. The LEC then issues

an LE_ARP_REQUEST for the all 1s broadcast MAC address to obtain the ATM address of the

BUS. When the LE_ARP_RESPONSE is returned, the LEC establishes a Multicast Send VCC to

the BUS, and the BUS responds by adding the LEC to a pointtomultipoint Multicast Forward

VCC, at which time, the LEC is considered to be a member of the ELAN.

LECs can register LAN Destinations with the LES to ensure uniqueness and allow the LES to answer

LE_ARP_REQUESTs. Registrations include the LAN Destination and the ATM address that the

LEC associates with the LAN Destination. A LAN Destination may be either a MAC Address, or

a Route Descriptor if the LEC is integrated with a sourceroute bridge.


16/33

4

When a LEC needs to send a unicast frame to a LAN Destination for which it does not have a direct

connection, the LEC sends the frame to the BUS on the Multicast Send VCC. The LEC also sends

all multicast/broadcast frames to the BUS. The BUS is responsible for distributing these frames to

the appropriate destination(s). One simple way for the BUS to deliver these frames is to forwardthem to all LECs on a Multicast Forward VCC. More efficient approaches are described in Section

3. 2.

The LEC monitors the amount of unicast data sent to each LAN Destination through the BUS, and

when the traffic rate is sufficient to warrant direct communication with a particular LAN

Destination, the LEC initiates address resolution by transmitting an LE_ARP_REQUEST to the

LES. If the LAN Destination is registered, the LES responds with the associated ATM address.

Otherwise, the LES forwards the request on a Control Distribute VCC, and the LEC representing

the LAN Destination responds with an appropriate ATM address. Upon receiving the

LE_ARP_RESPONSE, the initiating LEC uses the ATM address to establish a Data Direct VCC,

and subsequent traffic to the LAN Destination is transmitted directly over this VCC.

Figure 1 below completes the overview by depicting physical and logical views of a simple LAN

Emulation network.

ATMSWITCH

LE Service

LECS LESa,b BUSa,b

LEC

LANDeviceDriver

Applications

ATMHost1 ELANa

LEC LEC

Bridging Function

Legacy Host1 ELANa Legacy Host2 ELANb

LANSWITCH

ATM Host2 ELANb

PHYSICAL NETWORK LOGICAL NETWORK

ELANa

ATMHost1

Legacy Host1

ELANb

ATM Host2

Legacy Host2

Figure 1. Physical and Logical Views of a Simple LAN Emulation Network


17/33

5

3. SCALEABILITYENHANCING DESIGN FEATURES

3. 1. DISTRIBUTED LANE SERVICES

The centralized aspects of the LE Service can be both advantageous and problematic. For example,

the LES/BUS represents a potential singlepointoffailure for an ELAN. Although the LANE

v1.0 Specification does not address LES/BUS redundancy, a number of vendors have recognized

that this singlepointoffailure is unacceptable in many production networks, and have added

extensions supporting failover to a backup LES/BUS [2]. Robustnessenhancing extensions of this

type have greatly aided customer acceptance of LANE products. Naturally, the next logical step is

to distribute the LE Service components in order to realize scaleability benefits along with the

increased reliability.

With a distributed LE Service, multiple LES/BUSs are available to service the clients of a single

ELAN. Thus, reliability is enhanced, since the clients of a failed LES/BUS may be reassigned to

any of the remaining LES/BUSs. Distributing the LE Services also addresses a number of

resourcerelated scaleability issues that can hinder deployment of largescale LANE networks. A

single LES/BUS instance may be limited in terms of processing power, forwarding throughput,

memory availability, or VCC capacity. However, with multiple LES/BUSs serving an ELAN, the

cumulative resources can be scaled up to meet the needs of the installation. Additionally,distributing the LE Services can decrease client join times during highactivity periods, such as

poweron sequences, by partitioning the signalling load across the ATM network.

In response to user requirements for these features, the ATM Forum is currently defining a standard

for distributing the LE Service. This standard is called the LANE NetworkNetwork Interface

(LNNI) Specification [3]. LNNI defines a protocol between LE Service components that enables

multiple LES/BUSs to cooperatively serve a single ELAN. LNNIenhanced servers will establish

VCCs explicitly for servertoserver communication, and exchange control and data frames over

these VCCs so that clients joined to different LESs may communicate directly (as if they were joined

to the same LES).


18/33

6

The LNNI Specification is currently in draft form; consequently, LNNI implementations may not

be available for quite some time. Additionally, existing LANE v1.0 servers will require software

upgrades to be able to participate in the LNNI protocol. To satisfy current requirements for

distributed LANE Services while protecting investments in existing technology, a new type ofinterconnection device may be deployed. This device implements Shortcut Bridging [4], an

enhanced version of transparent bridging.

When ELAN segments are bridged together using conventional techniques, independent LES/BUS

instances service each ELAN segment, and stations on different ELANs communicate by

establishing Data Direct VCCs to the bridge, which forwards interELAN traffic. Thus, conventional

ELAN bridging techniques can distribute the LE Service in a robust manner (since there are multiple

LES/BUS instances serving the collective set of clients and standard spanning tree protocols protect

against failure of the bridge itself). However, all interELAN traffic must pass through the bridge,

creating a potential bottleneck in terms of forwarding power and VCC resources. Shortcut bridging

solves this problem by enabling Data Direct VCCs to be established between devices residing on

different ELAN segments as illustrated in Figure 2 below.

To better understand shortcut bridging operation, suppose that Stationx in Figure 2 wishes to

communicate with Stationy, and that Stationx has issued an LE_ARP_REQUEST for the MAC

address ofStationy. Bridging LECx receives the LE_ARP_REQUEST, and the shortcut bridge either

answers the request (if it has a cache entry for the destination), or forwards the request to the LES

for ELANy through Bridging LECy. Assume LESy answers the LE_ARP_REQUEST. The

LE_ARP_RESPONSE is received byBridging LECy, and forwarded toLESx byBridging LECx.

LESx forwards the LE_ARP_RESPONSE on to Stationx, and Stationx then sets up a Data Direct

VCC to Stationy.

The fundamental difference between the operation of a shortcut bridge and that of a conventional

ELAN bridge is that the shortcut bridge returns the ATM address of the destination station, while

a conventional ELAN bridge would have returned the ATM address ofBridging LECx in responsetoStationxs LE_ARP_REQUEST. This is however a significant difference, since it preserves the

essence of belonging to the same ELAN by permitting clients to communicate directly over the

switched ATM network, and thereby enables the collection of bridged ELANs to function as a single

SuperELAN. In summary, shortcut bridging is a robust control mechanism for distributing the LE

Services in a standardsbased manner that builds upon proven characteristics of traditional bridging

techniques while eliminating the performance bottlenecks.


19/33

7

Bridging

LECx

Shortcut Bridge

ELANxLES/BUSx

Bridging

LECy

ELANy LES/BUSy

Shortcut Data Direct VCC

StationxStationy

Figure 2. Distributing the LANE Services with Shortcut Bridging

3. 2. BROADCAST MANAGEMENT

The propagation of broadcast traffic has been a deterrent to the deployment of largescale LANs in

many environments. Broadcast traffic brings the twin evils of consuming network bandwidth on

every LAN segment and creating perturbations at all end stations. Fortunately, these difficulties can

be managed in LAN Emulation networks by leveraging the centralized aspects of the LE Service,

which are an advantage when it comes to controlling broadcasts.

Since the BUS forwards all broadcast traffic, it is an ideal platform for intelligent broadcast

management functions. Broadcast management techniques are effective because most broadcast

frames are not actually intended for all stations. IP Address Resolution Protocol (ARP) requests are

a prime example. IP ARPs are intended for a particular station with an unknown MAC address.

For the ARP protocol to work, it is only necessary that the station with the specified IP address

receive the ARP request. Examples from other protocols include NetBIOS Name Queries, which

are conceptually similar to IP ARPs, and IPX RIP/SAP advertisements, which are only intended for

IPX routers and servers.

Figure 3 illustrates two broadcast management techniques, unicast conversion and directed

transmission, that can enhance the scaleability of LANE networks by reducing both network trafficand end station disturbances. In this example, the BUS has been augmented with aBroadCast

Manager (BCM) [2] component that transforms selected broadcasts into unicast frames. The

transformed frames are then transmitted directly to the destination LANE Client, and not to all

LANE clients. BCM operates by dynamically learning and caching the {protocol address, MAC

address, VCC} associations present in the network. To see how this works, lets examine the steps

depicted in Figure 3.


20/33

8

1) Assume the BCM IP cache already contains a mapping for the IP address ofStationy, and

that Stationx transmits an IP ARP request forIPy to the BUS.

2) The BUS recognizes the broadcast MAC address and passes the frame to BCM. BCM

examines the header and identifies the frame as an IP ARP request. BCM then obtains thecached entry for IPy and inserts a new cache entry for IPx. The cache entry maps the IP

address to the corresponding MAC address and identifies the Multicast Send connection to

the LEC representing the address.

3) Using the cached information, BCM converts the IP ARP request to a unicast frame by

inserting the proper destination MAC address, and transmits the frame directly to the

appropriate LEC on a Multicast Send VCC.

4) The unicast conversion extends BCM benefits to traditional LANs when the destination

station is located behind a bridge function.

Stationx Stationy

BUS

BCM

IP Cache

IPy, MACy, VCCyIPx, MACx, VCCx...

LAN

SWITCH

Unicast IP ARP Request(Dst MAC = MACy,Src MAC = MACx,Dst IP = IPy,Src IP = IPx)

Broadcast IP ARP Request(Dst MAC = all 1s,Src MAC = MACx ,Dst IP = IPy,Src IP = IPx)

2

13

4

Multicast Send VCCx Multicast Send VCCy

Figure 3. Managing Broadcasts at the BUS

BCM techniques are not limited to the BUS, and may be effective at any network junction that

processes a large amount of broadcast frames. For example, the techniques can be applied at a

shortcut bridge to create a broadcast management hierarchy, with BCM managing broadcasts within

an ELAN segment and a Bridging BroadCast Manager (BBCM) [4] component managing

interELAN broadcasts. Dynamic Protocol Filtering (DPF) [4] is another, complementary broadcastcontrol mechanism that can be utilized at shortcut bridges. DPF dynamically partitions the network

into Protocolspecific Virtual LANs (PVLANs) by monitoring the traffic received from each ELANto learn the protocols and subnets being used on that segment. Each PVLAN constitutes a broadcast

domain; thus, the scope of unmanaged broadcast/multicast packets for a particular protocol/subnet

is reduced to those segments that are actually utilizing the protocol/subnet. Figure 4 shows an

example configuration with four PVLANs: IP Subnet 1,IP Subnet 2 ,IPX Network 1 , andNetBIOS.

In this example, IP ARP traffic for destinations inIP Subnet 1 is restricted toELANa andELANc.

Likewise, IPX and NetBIOS traffic is also restricted to the indicated subset of ELANs.


21/33

9

BridgingLECa

PVLAN Shortcut Bridge

IP Subnet 1IP Subnet 2

BridgingLECc

IPX Net 1NetBIOS

IP Subnet 1

BridgingLECb

BridgingLECd

IP Subnet 2

BridgingLECf

IPX Net 1 NetBIOS

BridgingLECe

BBCM

ELANa ELANb ELANc ELANd ELANe ELANf

Figure 4. Managing Broadcasts at the Shortcut Bridge

3. 3. MANAGING IP MULTICAST TRAFFIC

Driven by Internetrelated developments, an increasing number of useful applications are emerging

that rely on IP multicast protocols to support multiple senders and receivers for purposes such as

collaborative computing and multimedia distribution. As these applications grow, so do the

demands on the network to provide techniques for efficiently delivering multicast traffic. The

traditional approach has been for hosts to advertise their interest in participating in a particular

multicast group using theInternet Group Management Protocol (IGMP) [5], and for routers to then

form a distribution tree using a multicast routing protocol, such as theDistance Vector Multicast

Routing Protocol (DVMRP) [6] orMulticast OSPF (MOSPF) [7].

IP multicast packets are transmitted with layer2 multicast addresses on LAN media, and if no

management techniques are employed within an ELAN, the multicast traffic will be forwarded to

all LECs by the BUS, with resulting problems akin to those associated with unmanaged broadcasts.

One approach to solving this problem is to add IP multicast management intelligence to the BUS.

The BUS could snoop IGMP messages in order to learn which LECs are supporting which IP

multicast groups, and then only forward multicast packets to the appropriate subset of LECs. Similarintelligence could also be added to the shortcut bridge to createIP Multicast PVLANs. A positive

attribute of this approach is that the support for managing IP multicast traffic is isolated within the

components providing the distributed LE Services, and no changes are required at the LECs.

However, the approach does not make optimal utilization of ATM network capabilities, as multicast

packets are replicated within the LE Service components, instead of simply being transmitted on a

pointtomultipoint VCC, which is ideally suited for delivering multicast traffic.


22/33

10

An approach that better utilizes the capabilities of the ATM network is illustrated in Figure 5 below.

Here, ELANs have been dedicated to particular IP multicast address ranges, and the LAN switches

have been enhanced to direct multicast traffic to the appropriate ELAN (i.e., only multicast traffic

for the associated group(s) flows on the dedicated ELANs). By also incorporating IGMP snoopingtechniques, the LAN switches can confine multicast traffic received from an ELAN to the LAN

segments containing hosts that are currently participating in the multicast group, which makes for

an efficient solution. Note that in this configuration, no special functions are required at the BUS.

The BUS simply forwards received traffic on a pointtomultipoint Multicast Forward VCC to all

the LECs in the ELAN, which happen to all be supporting members of IP multicast groups; thus,

no network bandwidth is wasted and no stations are unnecessarily disturbed. This simplicity of

function also makes it much easier to build hardware enabling linerate forwarding at the BUS.

Furthermore, the Multicast Forward VCCs established by these BUSs can be setup with QoS

parameters matched to the traffic requirements of the corresponding multicast groups, and the LECs

and LES/BUSs required for new Multicast ELANs can be created dynamically on an asneeded

basis.

BUSx

LEC LEC

LANSWITCH1

Groupz230.0.5.3

Groupx224.0.1.7

. . . LEC LEC

LANSWITCH2

Groupz230.0.5.3

Groupx224.0.1.7

. . . LEC LEC

LANSWITCHN

Groupz230.0.5.3

Groupx224.0.1.7

. . .. . .

BUSz. . .

Multicast Forward VCC (CBR)1.5 Mbps

Multicast Forward VCC (rtVBR)PCR = 5 Mbps

SCR = 500 Kbps

Multicast Address Ranges

ELANx: 224.0.1.5 229.0.5.10. . .

ELANz: 230.0.5.1 2234.0.5.10

Figure 5. Managing IP Multicasts with Dedicated ELANs

Version 2.0 of the LANE UserNetwork Interface (LUNI) Specification [8] helps with multicasttraffic management by specifying procedures that standardize the fundamental approach of

dedicating LE Service forwarding entities to multicast groups. LANE v2.0 LECs issue

LE_ARP_REQUESTs for multicast MAC addresses that they wish to transmit to, and are capable

ofaccepting multiple Multicast Forward VCCs. The LE_ARP_REQUEST provides the LES with

an opportunity to return the ATM address of a BUS that is dedicated to the multicast group, while

the capability of establishing multiple Multicast Forward VCCs provides the BUS considerable


23/33

11

flexibility in limiting the scope of multicast transmissions. In addition to these basic changes, LUNI

v2.0 also introduces an optional Selective Multicastfunction. LECs that support Selective Multicast

register the multicast MAC addresses for which they wish to receive traffic with the LES. This

registration allows the BUS to limit the multicast traffic sent to the LEC without performing anyIGMP snooping.

When compared with traditional routerbased approaches, LANEbased multicasting systems offer

several key advantages:

1) With LANEbased solutions, multicast traffic is logically separated from unicast traffic,

and all multicast packet forwarding decisions can be performed at layer2, even when the

destination is in a different subnet. This improves throughput and lowers latency by

replacing routing with switching on the multicast data path.

2) The procedures employed by multicast routing protocols to determine the properdistribution trees generate significant overhead. This is almost completely absent in a

LANEbased solution, thereby making better use of the available bandwidth.

3) The pointtomultipoint circuits that are built from the BUS to the LECs can be setup with

the desired Quality of Service characteristics, which is an important enabler for efficient

and easily managed QoSbased applications.

3. 4. CONTROLLING SIGNALLING RATES

Events such as poweron sequences and server failover can create situations where a large number

ofclients are simultaneously attempting to connect to the same LE Service component, which can

lead to unusually high signalling rates at the ATM switch providing access to the target LE Service

component. This can result in overflowed queues and delayed, if not denied, network service

because of the loss of signalling messages. Experience with LANE v1.0 has shown that

implementation of a random retry time interval at the LEC is quite effective in controlling signalling

rates and solving this problem. Unfortunately, use of a random retry time interval is not mandated

in the LANE v1.0 Specification (although it has been in the LUNI Version 2.0 Specification). Thus,

it is useful for the LES/BUS to also implement a signalling congestion control algorithm.

The LES/BUS can help control the signalling load by pacing the rate at which clients are added to

its pointtomultipoint connections when the ATM network is congested. If congestion is detected

(via cause codes in signalling messages), the LES/BUS should continue to accept pointtopoint

VCCs (i.e., Control Direct and Multicast Send VCCs), since rejecting these VCCs would only add

to the congestion, but delay adding the clients to the pointtomultipoint VCCs (i.e., Control

Distribute and Multicast Forward) for a random interval using an exponential backoff algorithm.


24/33

12

This temporal distribution of the signalling load lowers the probability of lost messages and thereby

expedites service restoration. Such an algorithm is required in largescale networks with LECs that

do not implement a random retry interval, and is advantageous in any case.

3. 5. DISTRIBUTED ROUTING

Design features supporting large ELANs have been described in the preceding sections. As ELANs

become larger, networks become flatter, which offers the dual benefits of simplicity and more

efficient utilization of highspeed switching infrastructures. When the number of subnets is

reduced, configuration is simplified, which naturally eases network management. Furthermore,

larger subnets tend to increase intrasubnet traffic within the enterprise, resulting in more direct

switched connections, with a corresponding reduction in routing bandwidth requirements for

intersubnet traffic. Nonetheless, there are still situations where routing functions are needed. For

example, security concerns or existing addressing conventions may dictate a more highly subnetted

design. TheNext Hop Resolution Protocol (NHRP) [9] was designed for these situations.

NHRP is an Internet Engineering Task Force (IETF) protocol that can improve network

performance by eliminating router hops on NonBroadcast MultiAccess (NBMA) subnetworks

like ATM. When internetworking protocols, such as IP, are run over ATM subnetworks, the routed

path may include multiple hops across the same ATM subnetwork. NHRP allows better utilization

of the underlying switched infrastructure by enabling the establishment of shortcut routes across

ATM subnetworks.

NHRP is a clientserver protocol. NHRP Clients (NHCs) issue requests to NHRP Servers (NHSs),

and NHSs either respond to the requests or forward the requests along the routed path. To initiate

establishment of a shortcut to a particular destination, an NHC transmits an NHRP Resolution

Request along the routed path. The NHS that serves the destination (e.g., when the destination

resides on a subnet local to the NHS) responds with an ATM address to be used in setting up a shortcut

VCC. In the bestcase, NHRP enableszerohop routing, where all router hops are removed from

the steadystate data path. Additionally, since the resolution requests follow the routed path,routerbased security capabilities are preserved in NHRP environments (as protocollayer access

controls may be applied to the resolution requests).

Although the NHRP Specification does not define support for LANE encapsulation, it does define

a generic, interoperable extension mechanism that can be readily utilized to extend the benefits of

NHRP to the large installed base of LANE equipment. NHRP support for LANE encapsulation is


25/33

13

particularly useful in onehop routing, where the ingress router establishes shortcuts on behalf of

hosts without NHCs as depicted in Figure 6 (i.e., whereRouter1 setups up an intersubnet shortcut

toLAN Switch2 on behalf ofIP Hostx for traffic destined toIP Hosty). Onehop routing is attractivebecause no end system changes are required.

ATM

LANSwitch1

Ethernet ELAN

IP Subnet9.1.3

IP Subnet9.1.2

TokenRing ELANIP Subnet

9.1.1

NHRP/Router1

LEC1

LAN Switch2

LEC2

IP Hosty

9.1.3.1IP Hostx

9.1.1.1

IP Hostw

NHRP/Router2

LEC

Intersubnet Shortcut LANE Data Direct VCCs

Figure 6. OneHop Routing in a LANE Environment

NHRP support for LANE encapsulation also provides the basis for extending the benefits of

zerohop routing to stations residing on traditional LAN segments throughRoute Switching. Route

Switching is the ultimate form of edge routing, with layer3 forwarding decisions distributed across

LAN stations. To achieve this, NHC function is included in the LAN stations. Route Switching

Clients dynamically learn the MAC addresses of NHSs and monitor the traffic flows destined for

these MAC addresses. The rate of traffic to a particular layer3 destination can then trigger ashortcut request. A shortcut is requested by sending an NHRP Resolution Request to the NHS.

These requests use the MAC address family as opposed to the ATM address family. The MAC

address associated with the destination protocol address is provided in the NHRP Resolution Reply.

Upon receiving the reply, the Route Switching Client substitutes the destination MAC address for

the routers MAC address and frames are then switched endtoend bypassing all intermediate

routers as shown in Figure 7.


26/33

14

Intersubnet Shortcut Data Direct VCC

ATM

LAN SwitchLAN Switch

ELAN IP Subnet

9.1.3.0

ELAN IP Subnet

9.1.2.0ELAN IP Subnet

9.1.1.0

LAN IP Subnet

9.1.1.0

IP HostA IP HostB

ProtocolStack

ProtocolStack

Like Media(both Ethernet or both TokenRing)

NHRP ClientFunction

NHRP ClientFunction

NHS/Router NHS/Router

LAN IP Subnet

9.1.1.0

Figure 7. ZeroHop Routing with Route Switching


27/33

15

4. WAN DEPLOYMENT ISSUES

ATM provides the capabilities to easily extend an ATM LAN across a Wide Area Network given

that there are essentially no distance limitations inherent in ATM as a data link layer protocol. This

property of ATM permits Local Area Networks to be extended across a WAN at high speeds, such

as DS3 and OC3, allowing workgroups to be formed that span many different sites while emulating

a single LAN using ATM switching. At these speeds, there will be no discernible difference between

communicating with local and remote stations on the LAN.

Although LANE v1.0 provides all the capabilities needed to stretch an ELAN across the WAN,

single LES/BUS architectures are not the most efficient solution for WAN environments, where

network resources are more precious. For example, consider the network shown in Figure 8 with

four sites spread across the United States. With the LE Services located in Seattle, four VCCs across

the WAN are required to connect each of the LECs in the other sites to the LES/BUS, and address

resolution requests generated by these LECs will need to traverse the WAN, even when the target

station is located at the same site as the originator of the request.

Seattle

LES/BUS

LECs

DallasLECs

Raleigh

LECs

BostonLECs

Figure 8. WAN Configuration with Single LES/BUS Architecture

The distributed LE Service architecture depicted in Figure 9 eliminates the inefficiencies described

above by deploying a LES/BUS at each site. In this solution, the WAN is still used as a simple

transport network providing Switched Virtual Circuit (SVC) connectivity between LANE

components across the multiple sites. However, additional robustness and efficiencies can be


28/33

16

obtained by adding CentralOffice (CO) based LANE Services to the ELAN as illustrated in

Figure 10. The CObased servers are owned and maintained by a telecommunications

administrator, which is economical, since the same equipment can be reused for many different

customers. Thus, with secure partitioning between the ELAN domains, CObased services cansupport ELANbased Virtual Private Networks (VPNs).

Seattle

LES/BUS

LECs

Dallas

Raleigh

Boston

LES/BUS

LECs

LES/BUS

LES/BUSLECs

LECs

Figure 9. WAN Configuration with Distributed LES/BUS Architecture

Seattle

LES/BUS

LECs

Dallas

Raleigh

Boston

LES/BUS

LECs

LES/BUS

Central OfficeLANE Services

LES/BUS

LES/BUS Interconnection,Broadcast/Multicast Management

LECs

LECs

Figure 10. WAN Configuration with Distributed LES/BUS and COBased Services


29/33

17

One obvious advantage of the CO model over mesh interconnection is that, for an ELAN with n sites,

the number of LE ServicetoLE Service connections is reduced from O(n2) to O(n). CO servers

can achieve this reduction now by interconnecting the LES/BUSs with a shortcut bridge, and offer

a migration path to LNNI later when the standard is completed. CO servers can also provideLES/BUS facilities for small sites where it would be inefficient to support a local LES/BUS.

Additionally, CO servers are a convenient platform for deploying intelligent broadcast and multicast

management functions that preserve valuable WAN bandwidth. Similarly, CO services can be easily

extended to include an NHRPbased routing offering. Along with a distributed architecture

characterized by high scaleability and carriergrade reliability, security and monitoring capabilities

are also key attributes of central office servers.

4. 1. SECURITY ISSUES

To support Virtual Private Networks, CObased LANE Servers must be able to restrict data access

to Closed User Groups. This type of security can be realized at two levels. The first of these is the

physical layer, where ATM switches are cognizant of the permitted sourcedestination pairs, and

connections violating the rules are not allowed to complete. While physicallayer security is

effective, it can also be restrictive and cumbersome to administer on a largescale basis, which

brings us to the other option, applicationlayer security.

Applicationlayer security is obviously dependent upon the particular application. So, well use a

couple of examples to illustrate the concepts. The first example is LES/BUS security, where the task

is preventing unauthorized users from joining the ELAN. One basic applicationlayer security

approach is denial of information. This approach can be applied to LES/BUS security by not

providing the ATM address of the LES/BUS to ineligible users. Denial of information can make

it more difficult to breach security, but is clearly insufficient in the case of CObased servers. A

second applicationlayer approach is jointime security. Here, the LES/BUS validates clients at the

time they join the ELAN. One way that the LES/BUS can validate clients is to query the LECSs

ELAN assignment policy database. Use of the ATM address assignment policy, in conjunction with

address screening at the ATM switches, is an effective combination.

The second example involves shortcut bridging, where the task is to ensure that traffic remains

within the appropriate ELANs. This can be accomplished in a straightforward manner by simply

assigning each bridging LEC to a particular domain and only forwarding traffic over ports that are

in the same domain. Filtering may also be performed at the applicationlayer, as well as the

physicallayer. For example, many bridges include an extensive set of filtering capabilities that are


30/33

18

applied on a framebyframe basis. These same capabilities can be applied to address resolution

requests received by shortcut bridges to prevent shortcut establishment.

4. 2. MONITORING ISSUES

Effective management applications are crucial to the success of largescale LAN Emulation

networks. Simple Network Management Protocol (SNMP) [10] agents are needed at each ELAN

component to track configuration changes, manage faults, and monitor performance levels. As

many network elements, such as LECs and LES/BUSs, may be created or removed dynamically, a

systemwide view is required to monitor the network configuration. Each agent generates traps

when local configuration events occur. These traps are delivered to network management stations

where they are collected by configuration management applications that update graphical topology

maps depicting the current network configuration.

In addition to the configuration traps, traps are also needed for fault management and performance

monitoring purposes. For example, LANE failures may result in SNMP traps being delivered to

management stations permitting centralized management of the distributed system. Management

stations would typically respond to such a failure by changing the color of the affected network

element in the topology display, logging a message in a history file, and possibly paging the network

operator. Thus, the graphical displays create a visual capture of the current and past network, which

is a significant aid to timely analysis and response in the network control center.

Configurable triggers that generate alarms when the values of specified MIB elements cross upper

or lower thresholds are another important feature of an effective monitoring system. These triggers

may be based on elements in the standard MIBs developed by the ATM Forum, or on new elements

that have been added to Enterprise MIBs to enhance network manageability. While configuration

and fault management issues tend to be relatively straightforward, performance management is a

more challenging task. Although its easy to collect and display performancerelated statistics, like

the number of frames forwarded, its not easy to relate these statistics to meaningful management

issues such as identification of users that are abusing the network or determining when additional

capacity is needed. This is an area where additional work is needed as new tools that do a better job

of relating performance data to capacity planning would be of substantial value.

CObased servers also place some unique demands on the management system. One example is the

capability for users to control the configuration of their VPNs, preferably via the web, without being

able to impact the configuration of other users VPNs. Other examples include the ability to monitor

on a VPN basis, and acquisition of detailed statistical information permitting accurate billing.


31/33

19

5. CONCLUSION

It is becoming increasingly clear that ATM hardware is the technology of choice for the core of

telecommunication carrier and Internet Service Provider (ISP) networks. The protocols that will

run on this hardware and the role of ATM in local area networks are more controversial topics. As

one begins to look at the issues associated with collaborative computing and multicasting, it becomes

apparent that innovative architectures are going to be required to solve these complex problems.

Nonetheless, while these issues are being debated, LANE implementations are maturing and a

growing number of LANE networks are being deployed to carry multiprotocol traffic in campus

environments. Although there are scaleability and reliability issues associated with strictimplementations of the LANE v1.0 Specification, availability of products that implement the design

features described in this paper, coupled with economical WAN services, will enable the design of

networks that do not suffer from these drawbacks and are capable of growth across the enterprise.

With this momentum, LAN Emulation appears to be wellpositioned as a technology for building

largescale networks that support both existing applications and the new class of emerging

QoSbased applications.


32/33

20


33/33

REFERENCES

[1] ATM Forum, LAN Emulation Over ATM: Version 1 Specification,

AFLANELNNI0021.000, Jan. 1995.

[2] C. Alexander, etal., Quick Guide to the IBM Multiprotocol Switched Services (MSS) Server

Release 1.0, Tech. Rep. TR 29.2170, IBM, Aug. 1996 (available from

http://www.raleigh.ibm.com/tr2/tr2over.html).

[3] ATM Forum, LAN Emulation Over ATM Version 2 LNNI Specification Draft 8,

BTDLANELNNI02.08, Feb. 1997.

[4] C. Alexander, Quick Guide to the IBM Multiprotocol Switched Services (MSS) Server Release

1.1, Tech. Rep. TR 29.2260, IBM, May 1997 (available from

http://www.raleigh.ibm.com/tr2/tr2over.html).

[5] S. Deering, Host Extensions for IP Multicasting, RFC 112, Aug. 1989.

[6] D. Waitzman, C. Partridge, and S. Deering, Distance Vector Multicast Routing Protocol,

RFC 1075, Nov. 1988.

[7] J. Moy, Multicast Extensions to OSPF, RFC 1584, Mar. 1994.

[8] ATM Forum, LAN Emulation Over ATM Version 2 LUNI Specification,

AFLANE0084.000, July 1997.

[9] J. Luciani, D. Katz, D. Piscitello, and B. Cole, NBMA Next Hop Resolution Protocol

(NHRP), InternetDraft, .

[10] J. Case, M. Fedor, M. Schoffstall, and J. Davin, A Simple Network Management Protocol

(SNMP), RFC 1157, May 1990.

Omni product guide

Documents

Transcript of Omni product guide