[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
VRRP Working Group                                         Atul Bansal
INTERNET DRAFT                                          (FORE Systems)
draft-ietf-vrrp-lane-02.txt                                   Rob Enns
                                                    (Juniper Networks)
                                                         Vivek Menezes
                                                              (Pluris)
                                                        Rob Montgomery
                                                   (Cabletron Systems)
                                                    Ayikudy K.Srikanth
                                                        Hamayon Mujeeb
                                                     (Nortel Networks)
                                                     Expires June 2000


                 VRRP Operation over ATM LAN Emulation


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Draft can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of in Internet-Drafts Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Abstract

   This memo specifies the application of the Virtual Router Redundancy
   Protocol (VRRP) over networks built using the ATM Forum LAN Emulation
   protocol (LANE).  The memo specifies the behavior required of a LANE
   client (LEC) in order to interoperate with VRRP.

   Two schemes "Proxy LEC Scheme" and "Non-Proxy LEC Scheme" are
   outlined for running VRRP over LANE.  Both schemes can be deployed



Bansal, et al.                                                  [Page 1]


INTERNET DRAFT                                         Expires June 2000


   simultaneously in the network.


1. Introduction

   The Virtual Router Redundancy Protocol (VRRP) [1] specifies a
   protocol used to provide dynamic failover in forwarding
   responsibility for a set of IP addresses.  VRRP provides high
   availability of a default forwarding path without requiring hosts to
   run routing or router discovery protocols.

   ATM Forum LAN Emulation (LANE) [2,3] specifies a protocol used to
   emulate Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 LANs on an
   Asynchronous Transfer Mode (ATM) network.  LANE is used to extend LAN
   connectivity over an ATM backbone.

   This memo specifies the behavior required of a LANEv2 client in order
   to interoperate with VRRP.  The behavioral difference between the
   LANEv2 client and LANEv1 client is described in section 7 so that a
   LANEv1 client can interoperate with VRRP.


2. Discussion

   VRRP operates by electing a master router which responds to a well
   known virtual MAC address (VMAC) for the virtual router.  When a new
   master router is elected, the physical device responding to the VMAC
   may change.  LANE operates by maintaining  a set of mappings from MAC
   addresses to ATM addresses.  When running VRRP on a LANE network, the
   LANE protocol must be notified when a new master router is elected so
   that it can update the MAC address to ATM address mapping within the
   ELAN for the virtual router's MAC address.  In essence while running
   VRRP over LANE a virtual MAC address may change location from one LEC
   to another.

   Some Definitions:

   1) ADDRESS ASSOCIATION:
      When a LEC represents a particular virtual MAC address the virtual
      MAC address is "associated" with the LEC.  No two LECs should be
      associated with the same MAC address in an ELAN.

   2) ADDRESS DISASSOCIATION:
      When a LEC stops representing a virtual MAC address which it
      apriori represented it is said to have disassociated itself from
      the virtual MAC address.

   3) Proxy LEC



Bansal, et al.                                                  [Page 2]


INTERNET DRAFT                                         Expires June 2000


      A LEC which doesn't register its MAC address associations with the
      LES.  A proxy LEC is responsible for replying to LE_ARP requests
      for the MAC addresses it is associated with.

   4) Non-Proxy LEC
      A LEC that registers its MAC address associations with the LES.
      The LES is responsible for replying to LE_ARP requests for MAC
      addresses registered by a non-proxy LEC.

   5) Targetless LE_ARP_REQUEST:
      As defined in section 7.1.30 of [3].
      "An LE Client MAY generate an LE_ARP_REQUEST with the
      TARGET-LAN-DESTINATION  field indicating not present, but with
      the SOURCE-LAN-DESTINATION,  SOURCE-ATM-ADDRESS, and optionally,
      the LLC-Muxed-ATM-Address TLV present.  This allows the generating
      LE Client to advertise an LE_ARP cache binding to  all other LE
      Clients in its ELAN.  An LE Client receiving a targetless
      LE_ARP_REQUEST MUST delete any LE_ARP cache bindings to that
      SOURCE-LAN-DESTINATION, and MAY replace any such bindings with
      the information  from the LE_ARP_REQUEST.

      If an LE Client sends out a targetless LE_ARP_REQUEST for a
      currently registered unicast LAN Destination, it must have the
      same bindings and TLVs as the most recent LE_REGISTER_REQUEST
      for that LAN Destination sent to the LE Server.

      An LE Client receiving a targetless LE_ARP_REQUEST for a
      SOURCE-LAN-DESTINATION  not in its cache SHOULD ignore the
      request.  An LE Client receiving a targetless  LE_ARP_REQUEST
      for a SOURCE-LAN-DESTINATION that is in its cache SHOULD update
      that cache entry with the information in the LE_ARP_REQUEST.
      This technique ensures that the LE Client has up-to-date
      information, without filling its LE_ARP cache entries for which
      it has no use."

   6) No-source LE_NARP_REQUEST:
      As defined in section 7.1.31 of [3].
      "An LE Client MAY generate a no-source LE_NARP_REQUEST to notify
      other clients that it no longer represents the unicast LAN
      Destination in TARGET-LAN-DESTINATION  and TARGET-ATM-ADDRESS
      (and LLC-Muxed-ATM-Address TLV, if present).  In this case,
      SOURCE-ATM-ADDRESS MUST be zero." On receiving a
      No-Source LE_NARP_REQUEST a LEC should remove the
      TARGET-LAN-DESTINATION to TARGET-ATM-ADDRESS mapping from its
      ARP cache.


   In VRRP virtual MAC addresses can change their associations with LEC.



Bansal, et al.                                                  [Page 3]


INTERNET DRAFT                                         Expires June 2000


   Since there are two differenct LEC configurations in an ELAN (Proxy
   and Non-Proxy) we discuss ADDRESS ASSOCIATION with both types.

   Two common configurations are envisioned when running VRRP over LANE.
   In the first, the LANE client (LEC) is co-located with the router
   running VRRP.  In other words, the LANE client represents one of the
   router's network interfaces.  In the second scenario, a router
   attached to a LAN such as Ethernet is located behind a bridge running
   a LANE client.  The scenarios are considered in detail in the
   following sections.


2.1 Scenario 1  ATM only Attached VRRP Routers

   In this scenario we assume the all routers running VRRP are attached
   to the LANE network.  This scenario is analogous to the first sample
   configuration in [1], replacing the Ethernet/Token Ring/FDDI network
   with a LANE network.

                      VRID=1
                     +-----+      +-----+
                     | MR1 |      | BR1 |
                     |     |      |     |
                     +-----+      +-----+
        IP A ---------->*            *<--------- IP B
                        |            |
                        |            |
                        |            |
         @@@@@@@@@@@@@@@+@@@@@@@@@@+@@@@@+@@@@@@@@+@@@@@@@@+@@@@@@@@+@@
                                         ^        ^        ^        ^
                                         |        |        |        |
                                       (IP A)   (IP A)   (IP A)   (IP A)
                                         |        |        |        |
                                      +--+--+  +--+--+  +--+--+  +--+--+
                                      |  H1 |  |  H2 |  |  H3 |  |  H4 |
                                      +-----+  +-----+  +--+--+  +--+--+

     Legend:
              @@@+@@@+@@@+@@  =  LANE network
                           H  =  Host computer
                         MR1  =  Master Router
                         BR1  =  Backup Router
                           *  =  IP Address
                        (IP)  =  default router for hosts

   In the above configuration, the end-hosts install a default route to
   virtual router #1's IP Address (IP A).  All the end-hosts (H1-H4)
   bind (IP A) with the virtual router's (VRID=1) virtual MAC address



Bansal, et al.                                                  [Page 4]


INTERNET DRAFT                                         Expires June 2000


   (VMAC1) which in turn is bound to MR1's link layer address (MR1 LEC's
   ATM Address).

   Upon MR1 failure,  BR1 becomes the master and sends out VRRP
   advertisement and its LEC ASSOCIATES itself with VMAC1.


2.2 Scenario 2  ATM and LAN Network Attached

   In this scenario we assume that all routers running VRRP are attached
   to the LAN network behind the bridges.  Furthermore, there are two
   virtual routers backing each other.  Half of the hosts are using one
   virtual router and the other half of the hosts are using the second
   virtual router.

                    VRID=1
                    +-----+
                    | MR1 |
                    |  &  |       +-----+
                    | BR2 |       | H3  |
                    +-----+       +--+--+
        IP A --------->*             |
                       |           (IP A)
                       |             |
            -------+---+-------------+--
                   |
               +---+---+               +-----+     +-----+
               |  B1   |               |  H1 |     |  H2 |
               |       |               +--+--+     +--+--+
               +---+---+                  |           |
                   |                   (IP A)      (IP B)
                   |                      |           |
         @@@@@@@@@@+@@@@@@@@@@@@@@@+@@@@@@+@@@@@@@@@@@+@@@@@@
                                   |
                               +---+---+
                               |  B2   |
                               |       |
                               +---+---+
                                   |
                         -+--------+---+------
                          |            |
                        (IP B)         |
                          |            *<---------- IP B
                       +--+--+      +--+--+
                       |  H4 |      | MR2 |
                       +-----+      |  &  |
                                    | BR1 |
                                    +-----+



Bansal, et al.                                                  [Page 5]


INTERNET DRAFT                                         Expires June 2000


                                    VRID=2


     Legend:
              @@@+@@@+@@@+@@  =  LANE network
              ---+---+---+--  =  Ethernet network
                           H  =  Host computer
                    MR1, MR2  =  Master Router
                    BR1, BR2  =  Backup Router
                       B1,B2  =  LANE Bridges
                           *  =  IP Address
                        (IP)  =  default router for hosts

   In the above configuration, MR1 is the master for virtual router #1
   serving IP address (IP A) and MR2 is the master for virtual router #2
   serving IP address (IP B).  The end-hosts H1 and H3 install a default
   route to the IP address of virtual router #1 (IP A) and bind (IP A)
   with VMAC of the virtual router #1 (VMAC1) which in turn is bound to
   the Bridge1's ATM Address (VMAC1 is behind bridge 1).  Similarly,
   end-hosts H2 and H4 install a default route to (IP B) and bind VMAC2
   to Bridge2's ATM address.

   Upon MR1 failure, BR1 becomes the master and sends out the VRRP
   advertisement with VMAC1 as the source MAC address.  The VRRP
   advertisement triggers Bridge 1 and  Bridge2  to update their station
   learning cache.  Upon detecting the station move, bridge B1 makes an
   ADDRESS DISASSOCIATION from VMAC1 and bridge B2 makes an ADDRESS
   ASSOCIATION with VMAC1

   Another topology in Scenario 2 can have ATM attached as well as LAN
   attached VRRP Routers.  In this case, the ATM attached VRRP Router
   can use either Proxy or Non-Proxy LEC Scheme and the LANE bridges use
   Proxy LEC Scheme.


3.0 Detailed Description of VRRP over LANE


3.1 Non-Proxy LEC Scheme

   This scheme is applicable when an ADDRESS ASSOCIATION or ADDRESS
   DISASSOCIATION is made by a Non-Proxy LEC.

   A LEC joins the ELAN as a non-proxy client.  It registers with LES
   the physical MAC address associated with the ELAN interface.

   On having to make an ADDRESS ASSOCIATION with VMAC the LEC registers
   the VMAC with the LES and sends out a "Targetless LE_ARP_REQUEST"



Bansal, et al.                                                  [Page 6]


INTERNET DRAFT                                         Expires June 2000


   with the VMAC to its own ATM address binding.  If the VMAC
   registration fails, the master must persist with the registration
   phase.  The LEC continues to send the Targetless LE_ARP_REQUESTS
   (subject to the generation time limits defined in [3]) every second.
   (In case of LANE v1 client, send LE_NARP with VMAC as the TARGET-LAN-
   DESTINATION and with zero TARGET-ATM-ADDRESS and zero SOURCE-ATM-
   ADDRESS)

   If a Non-Proxy LEC makes an ADDRESS DISASSOCIATION it unregisters the
   VMAC and sends out "No-Source LE_NARP" with the VMAC to its own ATM
   address mapping.

   If the VRRP router fails without being able to make an ADDRESS
   DISASSOCIATION, the LES detects the Control VC failure to the LEC
   associated with the VMAC and deletes the current VMAC to ATM binding.
   Other LECs in the ELAN will lose their VCs to the failed VRRP router.
   There is a potential failure mode if the control VC to the LES isn't
   dropped when the master router fails.

   Note that the ATM switch can only detect User-Network Interface (UNI)
   failure and not the LEC failure.  The ATM UNI signalling protocol [4]
   specifies a mechanism for detecting the interface failure between the
   ATM switch and the ATM host.  This mechanism relies on receving the
   AAL failure notification from the Signalling ATM Adaption Layer
   (SAAL).  Upon receiving the AAL failure notification, UNI signalling
   waits for the duration specified by the T309 timer value (default is
   4 secs) before releasing all active calls on the failed interface.

   The SAAL layer [5,6,7] provides reliable transport of signalling
   messages between peer entities (e.g., ATM switch and host) and
   provides mechanism for detecting the faliure between the peer
   entities.  Upon detecting the failure between the peer entities, the
   SAAL layer notifies the signalling Layer via AAL failure
   notification.

   Some ATM switch implementations release all VCs on the failed
   interface upon link carrier loss.  This memo recommends to use
   release on carrier loss feature if available.  Otherwise, this memo
   recommends that both UNI and SAAL timers must be set to detect the
   UNI failure under 3 seconds.  Upon the UNI failure detection, the ATM
   switch must immediately release all VCs related to the failed link.


3.2 Proxy LEC Scheme

   This scheme is applicable to a Proxy LEC that makes ADDRESS
   ASSOCIATION and ADDRESS DISASSOCIATION.




Bansal, et al.                                                  [Page 7]


INTERNET DRAFT                                         Expires June 2000


   The LEC must register as a proxy client and can optionally register
   its own MAC address with a LES (for pings, TELNET, SNMP, etc.).

   On making an ADDRESS ASSOCIATION a LEC sends out a "Targetless
   LE_ARP_REQUEST" with the VMAC to its own ATM address binding.  It
   also makes LE_ARP_REQUEST for this VMAC address.  If it gets a
   successful reply then it should persist sending "Targetless
   LE_ARP_REQUEST" until no reply is received.  This retransmission
   should not occur more frequently than once per second.  (In case of
   LANE v1 client, send LE_NARP with VMAC as the TARGET-LAN-DESTINATION
   and with zero TARGET-ATM-ADDRESS and zero SOURCE-ATM-ADDRESS)

   When the LEC makes an ADDRESS DISASSOCIATION it sends out "No-Source
   LE_NARP" with the VMAC to its own ATM address mapping.


3.3 State Description

   This section augments the state description defined in Sec 6.4 of
   [1].


3.3.1 Initialize

   Register either as a Proxy LEC or as a Non-Proxy LEC and complete the
   LANE JOIN PHASE [3].
   - If the Priority = 255

        o Make an ADDRESS ASSOCIATION with the VMAC
        o Send an ADVERTISEMENT
        o ...(same as [1])
        o Transition to the {Master} State
     else
        o ...(same as [1])
        o Transition to the {Backup} State


3.3.2 Backup

   While in this state, a VRRP router must do the following:

   - MUST not respond to ARP requests for the IP address(es)
     associated with the virtual router.
   - MUST not respond to LE_ARP_REQUEST for VMAC
   - ...(same as [1])

   - If the Master_Down_Timer fires, then
        o Make an ADDRESS ASSOCIATION with the VMAC.



Bansal, et al.                                                  [Page 8]


INTERNET DRAFT                                         Expires June 2000


        o send an ADVERTISEMENT
        o Broadcast a gratuitous ARP .....
        o ...(same as [1])
        o Transition to the {Master State}
     endif


3.3.3 Master

   While in the {Master} State the router functions as the forwarding
   router for the IP address(es) associated with the virtual router.

   While in this state, a VRRP router must do the following:

   - MUST respond to ARP requests for the IP address(es)
     associated with the virtual router
   - MUST respond to LE_ARP_REQUEST for VMAC
   - ... (same as [1])
   - If a shutdown event  is received, then
     o cancel the Adver_Timer
     o send an ADVERTISEMENT with Priority = 0
     o Make an ADDRESS DISASSOCIATION with the VMAC.
     o Transition to {initialize} state
     endif
   - ... (same as [1])
   - If an ADVERTISEMENT is received, then
     ... (same as [1])
        If the Priority in the ADVERTISEMENT is greater than the local
        Priority
        or
        If the Priority in the ADVERTISEMENT is equal to the local
        Priority and the the Primary IP address of the sender is greater
        than the local primary address, then:
          o Make an ADDRESS DISASSOCIATION with the VMAC.
          o Transition to {Backup} state


4.0 Requirement on the LANE Bridges for the VRRP Operation over LANE

   A LANE bridge must register as a proxy client with LES.  This is the
   default for LANE bridges.  A VRRP router could attach on a LAN port
   of a LANE Bridge.

   A LANE bridge must make ADDRESS ASSOCIATION on an ELAN port with MAC
   addresses that it learns on other ports.  It must make ADDRESS
   DISASSOCIATION when it learns an a MAC address on an ELAN  port on
   which it has made an ADDRESS ASSOCIATION with the same MAC.




Bansal, et al.                                                  [Page 9]


INTERNET DRAFT                                         Expires June 2000


   The ADDRESS ASSOCIATION and ADDRESS ASSOCIATION by LANE bridges upon
   detecting the station move is  essential for  the correct operation
   of VRRP in various extended LAN topologies.  This behavior should be
   default behavior for all LANE bridges independent of VRRP.


5.0 VRRP operation over Token Ring LANE networks

   The operation of VRRP over LANE Token Ring is similar to the Ethernet
   LANE case discussed above.  However, as discussed in [1] RFC 2338,
   VRRP over token ring requires the use of a token ring functional
   address for the VRID virtual MAC address because of the absence of a
   general multicast mechanism over old and new token ring adapter
   implementations.  The token ring functional address support is the
   only generally available multicast mechanism.

   The hosts on a Token Ring LANE subnet will use the Token Ring
   functional address as the destination MAC address for all IP traffic
   going through the IP address(s) of the virtual router.  As the
   functional address is a multicast address, all such traffic goes
   through the ATM LANE BUS, causing a potential congestion of the BUS.

   VRRP implementations over pure Token Ring LANE networks (Scenario 1)
   should use IEEE 802 MAC Address used for Ethernet, that is,
   00-00-5E-00-01-{VRID}.  In this case, the lack of a real token ring
   adapter makes the need for a functional address a non issue.  In the
   case of token ring bridged environment, as long as the Master and
   all Backups are on LANE, hosts can be on LANE as well as on Token
   Ring and there is no need to use functional addresses.

   However, if the Master or any of the Backups is on a bridged Token
   Ring in a mixed network of bridged token ring and token ring
   emulation (Scenario 2), the use of functional addresses cannot be
   avoided.

   In the case of VRRP in a Token Ring Source route bridged LANE
   environment, either the Virtual MAC address or the functional address
   could be used but the route descriptor should not be configured.


6.0 Behavior difference between the LANE V1 vs. LANE V2 clients

   From 7.1.29 [3]. "An LE Client MAY generate an unsolicited
   LE_NARP_REQUEST to allow other clients to learn about a changed
   Remote LAN-ATM address binding.  This LE_NARP_REQUEST advertises that
   the generating LE Client believes that an old binding between TARGET-
   LAN-DESTINATION and TARGET-ATM-ADDRESS is no longer valid, and that
   the generating LE Client now serves the LAN destination.  An LE



Bansal, et al.                                                 [Page 10]


INTERNET DRAFT                                         Expires June 2000


   Client receiving a valid LE_NARP_REQUEST MAY delete any of its LE_ARP
   cache entries that match the TARGET-LAN-DESTINATION and TARGET-ATM-
   ADDRESS, and MAY replace such entries with the binding between
   TARGET-LAN-DESTINATION and SOURCE-ATM-ADDRESS.  The generating LE
   Client MUST include the ATM address of the LE Client which was
   previously representing the LAN destination.  The LLC-Muxed ATM
   Address TLV MUST NOT be included in a LANE v1 LE_NARP_REQUEST."

   The V1 LE_NARP_REQUEST message didn't consider the two separate cases
   of updating ATM address to MAC binding by LANE clients.  The first
   case is where a LEC who was serving the MAC address by providing the
   MAC to its own ATM address.  Now, the LEC does not representing the
   MAC and it has to inform other LECs about this fact.  The second case
   is where a LEC starts serving the MAC address and has to inform other
   LECs about this fact.

   LANEv2 defines two separate messages to handle these two cases.  "No-
   Source LE_NARP_REQUEST" handles the first case and "Targetless
   LE_ARP_REQUESTS" handle the second case.

   LANEv1 LE_NARP_REQUEST as defined in [1] can only be used by the
   client for the second case.  The VRRP operation with LANEv1 requires
   that the LANEv1 client send the LE_NARP_REQUEST with zero TARGET-ATM-
   ADDRESS and zero SOURCE-ATM-ADDRESS.  This is change from [2] and
   [3].  The LANEv1 and LANEv2 LES must forward this LE_NARP_REQUESTS to
   all LECs.  Upon receiving LE_NARP with the Target ATM address of
   0x00, all clients (proxy and non-proxy) should delete the MAC to ATM
   address mapping for the MAC listed in the TARGET-LAN-ADDRESS.


7.0 Security Consideration

   This memo does not define any new protocol packets.  Therefore, it
   follows the same security mechanisms as defined in [1,2,3].


8.0 Acknowledgments

   The authors would like to thank Nischal Sheth, Mike Kazar, Yevgeny
   Shakhnovich, Geetha Brown and Danny Mitzel for their comments and
   suggestions.


References

   [1] Virtual Router Redundancy Protocol, RFC 2338, Internet
       Engineering Task Force, April 1998.
       ftp://ftp.ietf.org/rfc/rfc2338.txt.



Bansal, et al.                                                 [Page 11]


INTERNET DRAFT                                         Expires June 2000


   [2] LAN Emulation over ATM Version 1.0, The ATM Forum, January, 1995.
       ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0021.000.pdf.

   [3] LAN Emulation over ATM Version 2.0 - LUNI Specification, The ATM
       Forum, July, 1997.
       ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0084.000.pdf.

   [4] The ATM Forum, ATM User-Network Interface (UNI) Signalling
       Specification, Version 4.0, July 1996.
       ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.pdf

   [5] ITU-T Q.2391 (Note 1), B-ISDN User-Network Interface Layer 3 for
       Basic Call/Control, March 1994

   [6] ITU-T Q.2110, B-ISDN Signalling ATM Adaption Layer - Service
       Specific Connection Oriented Protocol (SSCOP) (Note)

   [7] ITU-T Q.2130, B-ISDN Signalling ATM Adaption Layer - Service
       Specific Coordiation Function for support of signalling at the
       user-network interface (SSCF at UNI) (Note)

Authors'  Addresses

   Atul Bansal
   8221 Bell Lane
   Vienna, VA 22182 USA
   Phone: +1 703 876 3810
   Email: atulbans@aol.com

   Vivek Menezes
   Pluris
   10455 Bandley Dr,
   Cupertino, CA 95014 USA
   Phone: +1 408 861 4147
   Email: vivek@pluris.com

   Rob Enns
   Juniper Networks
   385 Ravendale Drive
   Mountain View, CA 94043 USA
   Phone: +1 650 526 8000
   Email: rpe@juniper.net

   Rob Montgomery
   Cabletron Systems
   Pease Training Center
   Box 5005, 35 Industrial Way
   Rochester, NH 03866-5005 USA



Bansal, et al.                                                 [Page 12]


INTERNET DRAFT                                         Expires June 2000


   Phone: +1 603 337 9258
   EMail: rmontgom@cabletron.com

   A.K.Srikanth
   Nortel Networks Inc
   600 Tech. Park Drwy.
   Billerica, MA 01821 USA
   Phone: +1 978 916 8226
   EMail: asrikant@baynetworks.com

   Hamayon Mujeeb
   Nortel Networks Inc
   600 Tech. Park Drwy.
   Billerica, MA 01821 USA
   Email: hmujeeb@nortelnetworks.com




































Bansal, et al.                                                 [Page 13]