IEEE
`
`pqmpunications
`
`May 2001 Vol. 39 No. 5
`
`MAGAZINE
`
`C 0
`
`riented
`9;perations and ManagemetI*.
`ii
`,
`N
`o I cs in Wireless Communication
`
`? .
`
`ps i
`
`sl
`
`404
`
`t
`
`\
`
`\
`\
`
`\„,
`
`'1r
`
`' aow
`
`*141.k
`
`""walltet..
`4:44.4*
`
`4008.
`41040. 441104: 14
`N 40'4116,
`41s1l4aslegltjv (z
`
`*MO
`
`sof
`
``441441AL
`
`= - A Publication of the IEEE Comm
`
`IEEE
`
`oloudflare = xh. it 1016„ er
`
`4
`air
`fr41111r4ap
`41111'
`
`•
`
`42-
`
`Cloudflare - Exhibit 1016, cover
`
`

`

`Can you ensure
`today's quality in
`tomorrow's network?
`
`Simplifies
`
`Tomorrow's VoIP technologies bring
`significant new challenges to network
`development and operations. The architects
`of next-generation networks require the ability to
`develop, validate and ratify this new technology —
`Inet's Spectral MGTM is the diagnostic solution.
`
`Spectra2 MG offers powerful applications to test
`media and associated signaling in the emerging
`packet-switch environments of next-generation
`networks. It allows carriers and equipment manu-
`facturers to verify network operation under true
`conditions and ensure network interoperability.
`Spectra2 MG offers Media Gateway (MG) and
`Media Gateway Controller (MGC) test tools,
`allowing developers to test these critical elements
`of the next-generation network.
`
`www.INET.com
`
`V
`
`I
`
`1
`
`Via•irl" Li;AARY
`C)
`i'AGINECRiNG
`
`ISON, Wi 5370,
`
`SOFTSWITCHING
`
`INTERCONNECT QUALITY OF
`MANAGEMENT
`SERVICE
`
`CUSTOMER
`CARE
`
`SPECIAL NETWORK
`STUDIES
`SECURITY
`
`DIAGNOSTICS WE SIMPLIFY
`
`NETWORKS Ine
`
`DALLAS
`
`FRANKFURT
`
`# bit 101641page 1
`sACE4outiflare
`LONDON
`PARIS
`# 44 at www.comsoc.org/productinnovations OR Circle # 44 on reader service card
`
`TOKYO
`
`Cloudflare - Exhibit 1016, page 1
`
`

`

`Director of Magazines
`Mark J. Karol, Avaya Inc. (USA)
`
`Editor-in-Chief
`G. S. Kuo, National Chengchi University (Taiwan)
`Senior Technical Operations Editor
`Roch H. Glitho, Ericsson Research (Canada)
`
`Senior Technical Editors
`Koichi Asatani, Kogakuin U. (Japan)
`Thomas M. Chen, Southern Methodist U. (USA)
`Harry Rudin, IBM Zurich (Switzerland)
`Kazem Sohraby, Lucent Tech: Bell Labs (USA)
`
`Technical Editors
`Nirwan Ansari, NJIT (USA)
`Christos Douligeris, U. of Miami (USA)
`Joan Garcia-Haro, Polytechnic U.
`of Cartagena (Spain)
`Silvia Giordano, EPFL (Switzerland)
`Sol Greenspan, GTE Labs (USA)
`Khaled Ben Letaief, Hong Kong U. of S. & T. (China)
`Pascal Lorenz, U. of Haute Alsace (France)
`Torleiv Maseng, Lund U. (Sweden)
`Stan Moyer, Telcordia (USA)
`John O'Reilly, U. College London (UK)
`Andrzej R.Pach, U. of Mining & Metallurgy
`(Poland)
`Algirdas Pakstas, U. of Sunderland/Lithuanian
`Acad. Sci. (UK and Lithuania)
`Michal P. Pioro, Warsaw U. of Techn./ Lund U.
`(Poland and Sweden)
`Ramjee Prasad, Aalborg U. (Denmark)
`Sirin Tekinay, New Jersey Institute of
`Technology (USA)
`Mehmet Ulema, Daewoo Telecom. Ltd. (USA)
`Naoaki Yamanaka, NTT (Japan)
`
`Feature Editors
`Book Reviews, Andrzej Jajszczyk,
`AGH University of Technology (Poland)
`CommuniCrostic Puzzle
`Paul Green (USA)
`Conference Calendar
`Anant Kumar Jain, Lucent (USA)
`Light Trai9"ic, S. Pasupathy, U. of Toronto
`(Canada)
`News and Events, Joe El-Batal, Ericsson (Canada)
`On Track
`Celia Desmond, World Class -
`Telecommunications (Canada)
`Scanning the Literature
`Nirwan Ansari, NJIT (USA)
`Amane Nakajima, IBM Corp. (Japan)
`Your Internet Connection
`Eddie Rabinovitch, Cervalis (USA)
`Broadband Access Series
`Steve Gorshe, NEC eLuminant Techn. (USA)
`Zdzislaw Papir, University of Mining and
`Metallurgy (Poland)
`Internet Technology Series
`Khaled Elsayed, Cairo U. (Egypt)
`Michah Lerner, AT&T Labs (USA)
`Lightwave Series
`Philip J. Lin, Tellabs Research Center (USA)
`Sudhir Dixit, Nokia (USA)
`Software & DSP in Radio
`Joe Mitola, The MITRE Corporation (USA)
`Zoran Zvonar, Analog Devices (USA)
`Standards
`Yoichi Maeda, NTT (Japan)
`Mostafa Hashem Sherif, AT&T (USA)
`Wireless Communications
`Willie W. Lu, Siemens (USA)
`Moshe Zukerman, U. of Melbourne (Australia)
`IEEE Production Staff
`Joseph Milizzo, Assistant Publisher
`Eric Levine, Advertising Sales Manager
`Susan Lange, Digital Production Manager
`Catherine Kemelmacher, Associate Editor
`Jennifer Porcello, Digital Production Associate
`Janet Swaim, Production Editor
`Joanne O'Rourke, Staff Assistant
`
`IEEE
`
`2
`
`Ciiinmunications
`
`MAGAZINE
`
`May 2001 Vol. 39 No. 5
`www.comsoc.orgi-ci
`
`IP-ORIENTED OPERATIONS AND MANAGEMENT
`GUEST EDITORS: ANDRZEJ JAJSZCZYK AND GEORGE PAVLOU
`
`77 GUEST EDITORIAL: IP-ORIENTED OPERATIONS AND MANAGEMENT
`go A MANAGEMENT AND CONTROL ARCHITECTURE FOR PROVIDING
`IP DIFFERENTIATED SERVICES IN MPLS-BASED NETWORKS
`As the Internet evolves toward the global multiservice network of the future, a key
`consideration is support for services with guaranteed quality of service. The
`proposed differentiated services framework is seen as the key technology to
`achieve this.
`PANOS TRIMINTZIOS, ILIAS ANDRIKOPOULOS, GEORGE PAVLOU, PARIS FLEGKAS, DAVID GRIFFIN,
`PANGS GEORGATSOS, DANNY GODERIS, YVES T'JOENS, LEONIDAS GEORGIADIS,
`CHRISTIAN JACQUENET, AND RICHARD EGAN
`
`MANAGEMENT OF QUALITY OF SERVICE ENABLED VPNS
`New emerging IP services based on differentiated services and the IP security
`architecture offer the level of communication support that corporate Internet
`applications need nowadays. However, these services add an additional degree of
`complexity to IP networks which will require sophisticated management support.
`TORSTEN BRAUN, MANUEL GUENTER, AND IBRAHIM KHALIL
`1 00 MANAGEMENT OF SERVICE LEVEL AGREEMENTS FOR
`MULTIMEDIA INTERNET SERVICE USING A UTILITY MODEL
`The efficient management of a quality level of Internet service is becoming
`increasingly important to both customers and service providers. The authors
`describe how service level agreements for multimedia Internet service can be
`managed and controlled.
`JONG-TAE PARK, JONG-WOOK BAEK, AND JAMES WON-KI HONG
`
`INTERNET ACCOUNTING
`The authors provide an introduction to Internet accounting and discuss the status
`of related work within the IETF and IRTF, as well as certain research projects.
`To understand Internet accounting, it is important to answer questions like
`"what is being paid for" and "who is being paid."
`AIKO PRAS, BERT-JAN VAN BEIJNUM, RON SPRENKELS, AND ROBERT PARHONYI
`
`THE IETF ACTIVITIES IN THE OPERATIONS AND MANAGEMENT AREA
`The Internet Engineering Task Force works on standardization of Internet related
`protocols. The work is divided into various areas. One of the areas is operations
`and management. The author provides first a summary of the areas that exist
`within the IETF and then describes in some detail the tasks for each of the
`Working Groups (WGs) in the operations and management area.
`BERT WIJNEN
`TOPICS IN WIRELESS COMMUNICATIONS
`1 18 THE WIRELESS ART AND THE WIRED FORCE OF SUBSCRIBER ACCESS
`The authors compare different technologies for subscriber access. Starting with the
`various transmission media characteristics of all systems, the well-known twisted
`pair lines with their corresponding digital subscriber line services are evaluated
`against wireless local loops, communications over ubiquitous power lines,
`high-bandwidth cable modems, and mobile radio.
`CHRISTIAN DREWES, WOLFGANG AICHER, AND JOSEF HAUSNER
`
`Cloudflare - Exhibtit 4,0,1,6j naclint
`
`• May 2001
`
`Cloudflare - Exhibit 1016, page 2
`
`

`

`2001 Communications Society Officers
`J. Roberto B. de Marca, President
`Celia Desmond, President-Elect
`Curtis A. Sitter, Jr., VP—Technical Activities
`Horst Bessai, VP—Membership Services
`Douglas N. Zuckerman, VP—Membership
`Development
`Alex Gelman, VP—Society Relations
`Harvey Freeman, Treasurer
`John M. Howell, Secretary
`
`Board of Governors
`The officers above plus Members-at-Large:
`Class of 2001
`Laura Cerchio, Leonard Cimini
`Roberta Cohen, William Tranter
`Class of 2002
`Tomonori Aoyama, Roberto Saracco
`Roch Guerin, Byeong Lee
`Class of 2003
`Elizabeth Adams, Ross Anderson
`Lawrence Bernstein, Harvey Freeman
`
`2001 IEEE Officers
`Joel B. Snyder, President
`Raymond D. Finlay, President-Elect
`Hugo M. Fernandez Verstegen, Secretary
`Dale Caston, Treasurer
`Bruce A. Eisenstein, Past President
`Daniel J. Senese, Executive Director
`Tom Rowbotham, Director, Division III
`
`IEEE COMMUNICATIONS MAGAZINE (ISSN 0163-
`6804) is published monthly by The Institute of Electrical
`and Electronics Engineers, Inc. Headquarters address:
`IEEE, 3 Park Avenue, 17th Floor, New York, NY 10016-
`5997, USA; tel: +1-212.705-8900; http://www.com-
`soc.orgi—ci. Responsibility for the contents rests upon
`authors of signed articles and not the IEEE or its members.
`Unless otherwise specified, the IEEE neither endorses nor
`sanctions any positions or actions espoused in IEEE
`Communications Magazine.
`ANNUAL SUBSCRIPTION: $23 per member per year
`included in Society fee. Non-member subscription: $160.
`Single copy $10 for members and $20 for nonmembers.
`EDITORIAL CORRESPONDENCE: Address to: Editor-
`in-Chief, G.S. Kuo, National Chengchi Universiy, Taipei,
`Taiwan 11623; tel: +886 2 86617453, fax: +886 2
`86617432, e-mail: gskuo@ieee.org.
`COPYRIGHT AND REPRINT PERMISSIONS:
`Abstracting is permitted with credit to the source. Libraries
`are permitted to photocopy beyond the limits of U.S.
`Copyright law for private use of patrons: those post-
`1977 articles that carry a code on the bottom of the first page
`provided the per copy fee indicated in the code is paid
`through the Copyright Clearance Center, 222 Rosewood
`Drive, Danvers, MA 01923. For other copying, reprint, or
`republication permission, write to Director, Publishing
`Services, at IEEE Headquarters. All rights reserved.
`Copyright 0 2001 by The Institute of Electrical and
`Electronics Engineers, Inc.
`POSTMASTER: Send address changes to IEEE
`Communications Magazine, IEEE, 445 Hoes Lane,
`Piscataway, NJ 08855-1331. GST Registration No.
`125634188. Printed in USA. Periodicals postage paid at
`New York, NY and at additional mailingoffices. Canadian
`Post International Publications Mail (Canadian
`Distribution) Sales Agreement No. 264075.
`SUBSCRIPTIONS, orders, address changes — IEEE
`Service Center, 445 Hoes Lane, Piscataway, NJ
`08855-1331, USA; tel: +1-732-981-0060; e-mail:
`address.change@ ieee.org.
`ADVERTISING:Advertising is accepted at the dis-
`cretion of the publisher. Address correspondence
`to: Advertising Manager, IEEE Communications
`Magazine, 305 East 47th Street, New York, NY
`10017-2394, USA.
`SUBMISSIONS: The magazine welcomes tutorial or
`survey articles that span the breadth of communica-
`tions. Submissionswill normallybe approximately 4500
`words, with no mathematical formulas, accompanied
`by up to six figures and/or tables, with up to 10 care-
`fully selected references. Electronic submissions are
`preferred, and should be sent to the Senior Technical
`Operations Editor at Imcrogl@lmc.ericsson.se, or four
`copies by mail to: Roch H. Glitho, Senior Technical
`Operations Editor, Ericsson Research Canada, 8400
`Decarie Blvd., Town of Mount Royal, Quebec, H4P
`2N2 Canada. All submissions are subject to review.
`
`VER8.
`
`126 WIRELESS INTERNET OVER LMDS: ARCHITECTURE AND EXPERIMENTAL
`IMPLEMENTATION
`The authors argue that the former emphasis only on multimedia and ATM-based
`communication over LMDS was a mistake. The most exciting prospect for LMDS
`should be in the role of enabling Internet and data services together with
`multimedia. We introduce a basic architecture for two-layer IP-LMDS based on a
`trial network built between 1996 and 2000.
`PETRI MAHONEN, TOMMI SAARINEN, ZACH SHELBY, AND LUIS MUNOZ
`
`ALSO IN THIS ISSUE
`134 QoS AND SERVICE INTERWORKING USING CONSTRAINT-ROUTE LABEL
`DISTRIBUTION PROTOCOL (CR-LDP)
`Introducing quality of service features to the IP/TCP protocol suite has become a
`hot topic of research in both industry and academia. Several architectures have
`been proposed for QoS support at the network layer (layer 3 in the OSI model).
`OSAMA ABOUL-MAGD AND BILEL JAMOUSSI
`140 THE ITU-T BICC PROTOCOL: THE VITAL STEP TOWARD AN INTEGRATED
`VOICE-DATA MULTISERVICE PLATFORM
`At the end of 1999, the ITU-T completed the first edition of the Bearer-Independent
`Call Control (BICC) protocol, just nine months after the start of this activity. The
`development of BICC can be considered historic. For the first time a full-fledged
`operator-grade PSTN/ISDN service can be offered over a variety of packet networks,
`using only standardized protocols.
`M. OSKAR VAN DEVENTER, IKO KEESMAAT, AND PIETER VEENSTRA
`146 EXPERIMENTS AND ENHANCEMENTS FOR IP AND ATM INTEGRATION:
`THE ITHACI PROJECT
`IthACI has been a European project of the ACTS framework concentrating on fast
`layer 2 forwarding methods for IP traffic based on labeled flow mechanisms. The
`approach is also known as IP switching and is considered promising for enhancing
`IP performance.
`ILIAS ANDRIKOPOULOS, GEORGE PAVLOU, PANGS GEORGATSOS, NIKOS KARATZAS,
`KOSTAS KAVIDOPOULOS, JURGEN ROTHIG, SIBYLLE SCHALLER, DIRK 00MS,
`AND PIM VAN HEUVEN
`156 A COMPARATIVE EVALUATION OF DECT, PACS, AND PHS STANDARDS
`FOR WIRELESS LOCAL LOOP APPLICATIONS
`In a comparative analysis performance and capacity of DECT, PACS, and PHS for
`wireless local loop (WLL) applications have been investigated. This article reports
`the results of both qualitative and quantitative analysis.
`OMID MOMTAHAN AND HOMAYOUN HASHEMI
`164 FUNDAMENTAL LIMITS AND POSSIBILITIES FOR FUTURE TELECOMMUNICATIONS
`Using fundamental physical and information theoretical relations, the author
`considered fundamental capacity limits and possibilities of fiber optical, cellular
`radio, and satellite communication systems. In a fiber to the home scenario more
`than 1 Gb/s equivalent circuit-switched capacity may well be feasible in the future.
`In a microwave cellular or satellite radio network for mobile subscribers it may well
`be feasible, although requiring low-cost very advanced electronics, to reach several
`tens of megabits per second.
`OLLE NILSSON
`168 INTERNATIONAL DIRECT DIALING QUALITY IN A COMPETITIVE TRANSITIONAL
`TELECOMMUNICATIONS MARKET
`The introduction of resale-based competition in international direct dialing services
`in January 1999 triggered a round of extremely fierce competition in Hong Kong's
`IDD market. In response, both the incumbent operator and new entrants had to
`adopt aggressive strategies to defend or gain market share.
`XU YAN AND JAMES Y. L. THONG
`
`Message from the President
`Society News
`Conference Calendar
`Solution to CommuniCrostic #218
`Conference Preview
`On Track
`
`9
`12
`26
`38
`40
`52
`
`Your Internet Connection
`Product Spotlights
`Global Communications Newsletter
`CommuniCrostic #219
`OFC Product Roundup
`Advertisers' Index
`
`56
`60
`69
`74
`175
`184
`
`4
`
`Cloudflare -
`
`c-1,0,1,Otcpagaeine • May 2001
`
`Cloudflare - Exhibit 1016, page 4
`
`

`

`THE ITHACI PROJECT
`
`Experiments and Enhancements for
`IP and ATM Integration:
`The IthACI Project
`
`Ilias Andrikopoulos and George Pavlou, CCSR, University of Surrey
`Panos Georgatsos, Nicholas Karatzas, and Kostas Kavidopoulos, Algonet S.A., Greece
`Jurgen Rothig and Sibylle Schaller, CCRL, NEC Europe Ltd., Germany
`Dirk Ooms, Alcatel Bell, Belgium
`Pim Van Heuven, IMEC, University of Gent, Belgium
`
`ABSTRACT
`IthACI has been a European project in the
`ALI'S framework concentrating on fast layer 2 for-
`warding methods for IP traffic based on labeled
`flow mechanisms. The approach is also known as
`IP switching and is considered promising for
`enhancing IP performance. Several flavors of IP
`switching have been proposed by various vendors
`(e.g., IP Switching by Ipsilon, Tag Switching by
`Cisco, ARIS by IBM, IPSOFACTO by NEC), all
`of them different and not interoperable. IP Switch-
`ing has been adopted by the IETF under the
`umbrella of Multi-Protocol Label Switching
`(MPLS).1 Although MPLS has made remarkable
`progress recently, a number of issues remain large-
`ly open for further investigation. The scope of the
`IthACI project was to address such issues and pro-
`pose solutions. The issues addressed were multi-
`cast, QoS, resource management, and mobility
`support in a multicast environment. IthACI con-
`ducted both theoretical and experimental work.
`Three network islands, each based on a different
`flavor of IP switching, were set-up and the interop-
`erability of these different IP switching/MPLS fla-
`vors were investigated and demonstrated.
`
`INTRODUCTION
`Since its inception around 1990, asynchronous
`transfer mode (ATM) network technology has
`been regarded as an antipode to existing Inter-
`net Protocol (IP) technology. ATM has started
`being deployed by traditional voice carriers
`(telephone companies), while IP is deployed by
`carriers of data traffic. ATM is considered to be
`fast, but complex, expensive, and ineffective for
`short-lived applications, mainly due to its con-
`nection-oriented nature. IP is regarded as sim-
`ple, mature, well proven and accepted over the
`
`years, but missing QoS functionality and result-
`ing in slow speeds due to the implementation
`routing functionality in software. Efficient meth-
`ods for combining IP and ATM technology and
`transporting IP traffic over ATM backbone
`infrastructure have been considered. The result
`is known as "IP Switching" — a kind of IP router
`with IP protocol functionality that employs ATM
`hardware for efficient data forwarding.
`Oyinally, various flavors of IP Switching
`were roposed: Ipsilon IP Switching, Cisco Tag
`Switching, IBM ARIS, Toshiba CSR, NEC
`IPSOFACTO, just to name a few. This prompt-
`ed the Internet Engineering Task Force (IETF)
`to address a standardized approach through a
`working group on multiprotocol label switching
`(MPLS).
`IthACI [1] (Internet and the ATM: Conver-
`gence and Integration) was a European
`Advanced Communications Technologies and
`Services (ACTS) project, which ran from March
`1998 to Dec 1999 with the overall scope to eval-
`uating and contributing to the different tech-
`nologies that permit the efficient transport of IP
`traffic over, private or public, ATM backbone
`infrastructure. In this context, the project
`addressed the requirements for efficient IP mul-
`ticasting, accommodation of QoS demands,
`mobility in a multicast environment, and
`resource management. It subsequently under-
`took enhancements of existing IP switching solu-
`tions with respect to the previous features, and
`generated recommendations based on experi-
`ence gained from implementation and experi-
`mentation.
`Besides the functional enhancements, the
`project's main goal was to influence the actual
`standardization process in the area of IP switch-
`ing, and thus to work within and bring the pro-
`ject results to the IETF MPLS working group.
`
`1 The terms MPLS and IP
`switching are used inter-
`changeably throughout
`this article.
`
`146
`
`0163-6804/01/$10.00 © 2001 IgiPudflare - Exhibik10,16 page 1,46
`,,,„
`
`• May 2001
`
`Cloudflare - Exhibit 1016, page 146
`
`

`

`The article describes the multicast, QoS, and
`resource management enhancements developed
`in the IthACI project. These enhancements led
`to certain advances in these areas, fed back to
`the MPLS working group. The tests carried out
`for validating the developed enhancements are
`also presented, summarizing the produced
`results and demonstrations and highlighting the
`experience gained.
`
`PROJECT OVERVIEW AND
`ADOPTED TECHNOLOGIES
`The IETF established a working group on MPLS
`in early 1997 in order to consider methods for
`label swapping based forwarding (label switching)
`in conjunction with network layer routing.
`Although restricted to neither any layer 2 tech-
`nology nor to a specific layer 3 routing protocol,
`IP over ATM2 (IP switching) is implemented as
`an important incarnation of MPLS.
`First, the IETF MPLS working group built up
`a general MPLS framework and architecture [1].
`So far, the main focus of the MPLS working
`group was on interoperability aspects, especially
`the Label Distribution Protocol (LDP), which
`provides the signaling facilities among the label
`switching routers (LSRs) and coordinates the
`distribution of label bindings aiming at setting
`up label switched paths (LSPs). Recently, work
`on traffic engineering issues in MPLS also beg
`There are a lot of issues in MPLS netw rks
`that require further investigation. Issues in the
`areas of multicast, QoS provisioning and
`resource management stimulated the IthACI
`project work [2]. Considering three existing IP
`switching technologies, the project undertook
`the design, implementation, and experimentation
`of a number of enhancements in these areas.
`The various IP switching techniques used
`within the IthACI project originate from three
`different sources: Tag Switching (available as a
`product by Cisco), IPSOFACTO/LCATM (a
`prototype for IP switching developed by NEC),
`and YALSA (a new IP switching prototype spe-
`cially designed for multicast within the IthACI
`project). A description of adopted IP switching
`technologies is given in the following sections.
`In order to achieve its objectives, the project
`did set up three independent islands, each
`employing one of the above-mentioned existing
`(proprietary) IP switching technologies. The
`islands and technologies were NEC's IPSOFAC-
`TO, the "Green Island;" CISCO's Tag Switch-
`ing, the "Blue Island;" and Alcatel's YALSA,
`the "Red Island."
`Project work resulted in enhancing the con-
`sidered technologies with features in the areas of
`multicast, QoS provisioning, resource manage-
`ment, and mobility in a multicast context, in
`order to provide added value to existing solu-
`tions. The islands were interconnected to demon-
`strate interoperability of the IP Switching
`techniques as well as the cooperation of the
`developed enhanced features.
`It should be noted that although the devel-
`
`2 Not to be confused with Classical IP over ATM.
`
`IEEE Communications Magazine • May 2001
`
`Project work
`resulted in
`enhancing the
`considered
`technologies with
`features in the
`areas of
`multicast, QoS
`provisioning,
`resource
`management,
`and mobility in a
`multicast context,
`in order to
`provide added
`value compared
`to existing
`solutions.
`
`oped enhancements were implemented in these
`technologies, the design was not limited to them.
`Project work followed the emerging specifica-
`tions from the IETF MPLS working group, and
`contributed to the ongoing MPLS work. More-
`over, the adopted baseline technologies them-
`selves moved by their manufacturers to comply
`with the MPLS specifications.
`
`IPSOFACTO/LCATM — IPSOFACTO [3] is a
`soft-state traffic-driven technique where each
`switch makes independent decisions about short-
`cuts for data flows.
`A node that wants to send a packet selects an
`unused virtual circuit identifier (VCI) on the
`appropriate outgoing link. The receiving IPSO-
`FACTO switch is configured to send all cells
`with an unassigned VCI to the switch controller.
`The switch controller reassembles the IP packet
`and then uses the IP routing table to decide how
`the packet should be forwarded. In this phase,
`the IPSOFACTO switch acts as a normal IP
`router. An unused VCI on the appropriate out-
`going link is selected, and the shortcut path is
`created when the switch controller informs the
`underlying switch to shortcut the incoming VCI
`to the outgoing VCI (route once, switch many). It
`should be clear that IPSOFACTO uses implicit
`upstream allocation: the upstream node selects a
`new VCI from a pool of unused VCIs. No label
`distribution protocol is necessary. The upstream
`node sends the first packet on an unused VCI.
`The downstream node reassembles this first
`packet to discover the label semantics (e.g., des-
`tination address) attached to the incoming VCI.
`The receiving switch learns the label semantics
`by inspecting the first packet of the flow. The
`first packet of a flow paves the way for the fol-
`lowing packets. Note that shortcut paths are
`never established for IP control messages.
`A characteristic of IPSOFACTO is that it was
`designed in the context of multicasting and mul-
`ticast routing right from the start, addressing the
`Distance Vector Multicast Routing Protocol
`'(DVMRP) and especially Protocol Independent
`Multicast (PIM). The multicast routing database
`is used to establish multicast forwarding state in
`the switch controller. IPSOFACTO maps this
`state to a (number of) point-to-multipoint VC(s)
`within the switch. A large part of the specifica-
`tion of IPSOFACTO deals with mapping PIM
`sparse mode (PIM-SM) and dense mode (PIM-
`DM) to the ATM switching paradigm.
`In the course of the IthACI project, the NEC
`IPSOFACTO implementation evolved to label
`switch controlled ATM (LCATM), a prototype
`that supports native IP multicast over MPLS as
`proposed by NEC to the IETF [4, 5]. LCATM
`employs the original IPSOFACTO ideas for
`multicast traffic, and uses the standard LDP pro-
`tocol and methods for MPLS unicast traffic. In
`the rest of this article the enhanced IPSOFAC-
`TO prototype is referred to as LCATM.
`
`YALSA — Yet Another Label Switching Archi-
`tecture is a flexible, modular architecture that
`allows implementing and testing various label
`switching methods. YALSA uses a dedicated
`lightweight label distribution protocol, with sig-
`naling between neighboring LSRs to advertise
`
`Cloudflare - Exhibit 1016, page 147
`
`1 d 7
`
`Cloudflare - Exhibit 1016, page 147
`
`

`

`Currently several
`
`multicast routing
`
`protocols
`
`are being
`
`implemented and
`
`standardized.
`
`These protocols
`
`expose different
`
`tree set-up and
`
`maintenance
`
`characteristics,
`
`which yield that
`
`some multicast
`
`routing protocols
`
`combine better
`
`with IP Switching
`
`than others.
`
`the association between a forwarding equiva-
`lence class (FEC) and a label.
`The LSRs in the YALSA Island can be con-
`figured to do label advertisement in either
`downstream or downstream-on-demand mode.
`The LSPs are set up in a distributed fashion —
`each LSR can independently decide to start a
`(partial) LSP — and the setup can be initiated
`by different triggers. For multicast LSPs the
`following triggers were tried: multicast routing
`protocol messages, changes to the multicast for-
`warding cache, and IGMP snooping. Conse-
`quently, YALSA can be configured to work in
`either traffic or topology-driven mode.
`
`Tag Switching — Cisco's Tag Switching was
`one of the first commercial attempts for short-
`cutting IP traffic on layer 2 paths. Cisco's Tag
`Switching is topology-driven and uses down-
`stream allocation on demand3 for label assign-
`ment. For each entry in its routing table, the
`upstream node asks the downstream node to
`provide a tag. The downstream node can either
`first ask its own downstream node for a tag
`and then reply to the upstream node, or reply
`immediately and then ask its downstream node
`for a tag.
`The Tag edge routers add tags (a synonym
`for labels) to packets and participate in the L3
`routing protocols. Tag edge routers can also
`perform additional L3 functionality such as
`security. The Tag Switches or Tag switch
`routers (TSRs) are the core nodes which for-
`ward packets based on tag values and also par-
`ticipate in the L3 routing protocols. TSRs do
`not add or remove tags; they only switch tags
`(translate the incoming tags to outgoing tags).
`The Tag Distribution Protocol (TDP) is the
`control protocol used by Tag switches and edge
`routers to request or distribute tag bindings.
`When distributing tag bindings, TDP also
`includes a hop count so the Tag edge routers
`can decrement the time to live (TTL) before
`transmitting the packets through the Tag
`switching network. TDP requests can be initiat-
`ed by any node at any time.
`When the switch controller has communicat-
`ed upstream bindings and received downstream
`bindings, it can instruct its switch to shortcut
`incoming tags to the appropriate outgoing tags.
`Tag Switching supports traffic engineering by
`allowing the establishment of explicitly routed
`(traffic engineered) paths and the routing of
`incoming traffic on them based on extended fil-
`ters on source, destination IP addresses and
`other information in the IP header.
`
`MPLS IN A
`MULTICAST ENVIRONMENT
`The multicast enhancements undertaken by the
`IthACI project aimed to apply MPLS-style short-
`cut techniques to IP multicast to optimize net-
`work performance without any modification to
`
`3 That is, when ATM is used as the underlying switching
`technology. The non-ATM-specific part of Tag Switching
`allows for other allocation strategies too.
`
`the end-user environment or to existing IP mul-
`ticast protocols. The shortcut point-to-multipoint
`ATM connections follow dynamically the tree
`topology changes that are the result of IP hosts
`joining or leaving a multicast group.
`At the time the IthACI project was defined,
`the IETF had just created a working group on
`MPLS. Within the working group, the focus was
`solely on unicast forwarding, with the application
`of label switching to IP multicast traffic not yet
`addressed. Within the project, network function-
`al models and algorithms were studied to enable
`MPLS for multicast flows. A prototype for MPLS
`multicast was defined, designed, and implement-
`ed to show the feasibility and scalability of label-
`switched multicast flows. This new approach to
`IP/label switching advanced the IETF MPLS
`standardization process.
`Currently several multicast routing protocols
`are being implemented and standardized:
`DVMRP, PIM-SM, PIM-DM, Multicast Open
`Shortest Path First (MOSPF), and Core Based
`Trees (CBT). These protocols expose different
`tree setup and maintenance characteristics, which
`indicate that some multicast routing protocols
`combine better with IP switching than others: for
`example, flood and prune protocols (DVMRP,
`PIM-DM) will create highly dynamic L2 trees,
`resulting in a lot of label advertisement signaling
`and label consumption. Also, some multicast
`routing protocols (e.g., PIM-SM, CBT) allow the
`use of a shared tree for all sources, which leads
`to less label consumption, but potential merging
`problems when ATM is the underlying layer.
`For multicast, the project selected PIM-SM
`as the routing protocol. This protocol is designed
`to efficiently route IP multicast datagrams to
`sparsely distributed wide area groups. The selec-
`tion of PIM-SM over, say, DVMRP or PIM-DM
`was mOily because of scalability issues. The pro-
`ject Os designed means for mapping multicast
`tree's/routes to shortcuts and has elaborated on
`multicast issues in MPLS networks in general.
`The multicast enhancements have been realized
`in the Green and Red Islands based on Alcatel's
`YALSA and NEC's IPSOFACTO/LCATM tech-
`nologies.
`Each of the Red and Green Islands used its
`own method to do the mapping of multicast
`streams onto layer 2 (L2) connections. IPSOFAC-
`TO/LCATM used an implicit label advertisement
`method, YALSA a dedicated protocol. A dedicat-
`ed protocol (e.g., LDP) has the disadvantage of
`needing to be developed from scratch. Label
`advertisements piggybacked onto PIM join/prune
`messages (Tag Switching) have several disadvan-
`tages. The periodicity of the messages creates
`more signaling than required, only downstream
`mode is possible, the deployment of each new
`multicast routing protocol demands adaptations
`to allow piggybacking, the method cannot be used
`for flood and prune protocols, and finally, it limits
`the scope of the MPLS domain in mixed (LSR
`and non-LSR) multi-access networks.
`Besides correct interworking of IP multicast
`and IP switching in the separate islands, another
`goal of the project was to demonstrate the inter-
`operability between the different multicast solu-
`tions, either on layer 2 or, as a fallback solution,
`on layer 3. Interoperability was demonstrated for
`
`148
`
`Cloudflare - Exhibikaltupages m ine . May 2001
`
`Cloudflare - Exhibit 1016, page 148
`
`

`

`the Alcatel and NEC (Red and Green Islands).
`Multicast shortcut paths were dynamically estab-
`lished between both prototypes, crossing the
`border between the two IP switching technolo-
`gies on layer 2 (Fig. 1).
`The multicast implementation in LCATM
`follows the traffic-driven methodology to switch
`IP multicast flows. When the first packet of a
`multicast flow is detected, LCATM sets up point-
`to-multipoint ATM VCs according to the corre-
`sponding entry in the multicast forwarding cache
`maintained by the PIM-SM routing software.
`The LCATM prototype supports native IP
`multicast over MPLS as proposed by NEC to the
`IETF [4, 5]. Basically this scheme maps the IP
`tree onto a per-source point-to-multipoint ATM
`tree, even for a core-centered approach like
`PIM-SM, in a traffic-driven way. In order to
`avoid PIM piggybacking, two modes of label