Subject: Re: Archive question

From: "PHILIP MATTHEWS" <[email-masked]>
Date: Mon, 01 Nov 1999 15:55:45 -0500

Eric:

And here is the second one.

- Philip Matthews, Newbridge Networks Corp.

Network Working Group                                      Eric C. Rosen
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: May 1997
                                                           Daniel Tappan
                                                     Cisco Systems, Inc.

                                                          Dino Farinacci
                                                     Cisco Systems, Inc.

                                                           Yakov Rekhter
                                                     Cisco Systems, Inc.

                                                            Guy Fedorkow
                                                     Cisco Systems, Inc.

                                                           November 1996

                   Tag Switching: Tag Stack Encodings

                      draft-rosen-tag-stack-00.txt

Status of this Memo

   This document is an Internet-Draft.  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."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Rosen, et al.                                                   [Page 1]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

Contents

    1    Introduction  .............................................   2
    1.1  Specification of Requirements  ............................   2
    2    Encoding the Tag Stack  ...................................   3
    3    Transporting Tagged Packets over PPP  .....................   5
    3.1  Introduction  .............................................   5
    3.2  A PPP Network Control Protocol for Tag Switching  .........   6
    3.3  Sending Tagged Packets  ...................................   7
    3.4  Tag Switching Control Protocol Configuration Options  .....   7
    4    Transporting Tagged Packets over LAN Media  ...............   7
    5    Security Considerations  ..................................   8
    6    Authors' Addresses  .......................................   8
    7    References  ...............................................   9

1. Introduction

   [1] describes a need to encode a "Tag Stack" into a packet.  This
   document specifies how the Tag Stack is encoded on Tagged Packets
   which are sent over PPP data links and over LAN data links.

1.1. Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

        MUST

        This word, or the adjective "required", means that the
        definition is an absolute requirement of the specification.

        MUST NOT

        This phrase means that the definition is an absolute prohibition
        of the specification.

        SHOULD

        This word, or the adjective "recommended", means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full implications must be understood and carefully
        weighed before choosing a different course.

Rosen, et al.                                                   [Page 2]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

        MAY

        This word, or the adjective "optional", means that this item is
        one of an allowed set of alternatives.  An implementation which
        does not include this option MUST be prepared to interoperate
        with another implementation which does include the option.

2. Encoding the Tag Stack

   On both PPP and LAN data links, the Tag Stack is represented as a
   sequence of Tag Stack Entries.  Each Tag Stack Entry is represented
   as a 4-byte quantity.  This is shown in Figure 1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag
   |                Tag                  |rsvd |CoS|S|     TTL     | Stack
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry

                       Tag:  tag value, 19 bits
                       rsvd: reserved, 3 bits
                       CoS:  Class of Service, 2 bits
                       S:    bottom of stack, 1 bit
                       TTL:  7 bits

                                 Figure 1

   The Tag Stack Entries appear after the end of all data link layer
   headers, but before any network layer headers.  The entry
   representing the top of the Tag Stack appears earliest in the packet.
   The entry representing the bottom of the Tag Stack appears latest.
   The network layer packet immediately follows the Tag Stack Entry with
   the S bit set.

   Each Tag Stack Entry is broken down into the following fields:

      1. Stack End Bit (S)

         This bit is set to one for the last entry in the Tag Stack
         (i.e., for the bottom of the stack), and zero for all other Tag
         Stack Entries.

      2. Time to Live (TTL)

         This seven-bit field is used to encode a time-to-live value.

Rosen, et al.                                                   [Page 3]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

         When the first tag is pushed onto an untagged IP packet, the
         TTL value in the Tag Stack Entry MUST be set to the smaller of
         127 and the value of the IP TTL field.

         At every hop which tag switches a packet, the TTL value of the
         packet's top Tag Stack Entry MUST be decremented by at least 1.

         When the Tag Stack is popped, and the resulting Tag Stack is
         non-empty,the TTL value in the new top stack entry MUST be
         decremented by 1.

         When the Tag Stack is popped, and the resulting Tag Stack is
         empty, and the network layer packet is an IP packet, the TTL
         value in the IP packet MUST be decremented by at least 1; it
         SHOULD be modified as follows.  If the TTL value in the IP
         packet is less than or equal to 127, it is replaced with the
         TTL value from the last Tag Stack Entry.  If the TTL value in
         the IP packet is greater than 127, it is replaced by the value
         which results from first subtracting the TTL value in the Tag
         Stack Entry from 127, and then subtracting that difference from
         the the TTL value in the IP header.  If this causes the TTL
         value in the IP header to become less than 1, the ordinary
         processing for an IP packet whose TTL has become less than 1
         MUST be performed.

         If at any time, the value of the TTL field in a Tag Stack Entry
         becomes less than 1, the packet MUST NOT be forwarded further.
         Depending on the tag value in the Tag Stack Entry, the packet
         may be silently discarded, or the packet may have its Tag Stack
         stripped off, and passed as an untagged packet to the ordinary
         processing for network layer packets which have exceeded their
         maximum lifetime in the network.

      3. Class of Service (CoS)

         This two-bit field is used to identify a class of service.

      4. Reserved

         These three bits are reserved.  They MUST be set to zero when
         writing, and MUST be ignored when reading.

      5. Tag Value

         This 19-bit field carries the actual tag value.

         A value of 0 represents the "Explicit NULL Tag".  The presence
         of the Explicit NULL Tag means that the Tag Stack must be

Rosen, et al.                                                   [Page 4]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

         popped, and the forwarding of the packet must then be based on
         the resulting top tag in the Tag Stack, or, if the Tag Stack
         becomes empty, on the network layer header.

3. Transporting Tagged Packets over PPP

   The Point-to-Point Protocol (PPP) [PPP] provides a standard method
   for transporting multi-protocol datagrams over point-to-point links.
   PPP defines an extensible Link Control Protocol, and proposes a
   family of Network Control Protocols for establishing and configuring
   different network-layer protocols.

   This section defines the Network Control Protocol for establishing
   and configuring Tag Switching over PPP.

3.1. Introduction

   PPP has three main components:

      1. A method for encapsulating multi-protocol datagrams.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols for establishing and
         configuring different network-layer protocols.

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure and test
   the data link.  After the link has been established and optional
   facilities have been negotiated as needed by the LCP, PPP must send
   Tag Switching Control packets to enable the transmission of tagged
   packets.  Once the Tag Switching Control Protocol has reached the
   Opened state, tagged packets can be sent over the link.

   The link will remain configured for communications until explicit LCP
   or Tag Switching Control Protocol packets close the link down, or
   until some external event occurs (an inactivity timer expires or
   network administrator intervention).

Rosen, et al.                                                   [Page 5]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

3.2. A PPP Network Control Protocol for Tag Switching

   The Tag Switching Control Protocol is responsible for enabling and
   disabling the use of tag switching on a PPP link.  it uses the same
   packet exchange mechanism as the Link Control Protocol (LCP).  Tag
   Switching Control Protocol packets may not be exchanged until PPP has
   reached the Network-Layer Protocol phase.  Tag Switching Control
   Protocol packets received before this phase is reached should be
   silently discarded.

   The Tag Switching Control Protocol is exactly the same as the Link
   Control Protocol [1] with the following exceptions:

      1. Frame Modifications

         The packet may utilize any modifications to the basic frame
         format which have been negotiated during the Link Establishment
         phase.

      2. Data Link Layer Protocol Field

         Exactly one Tag Switching Control Protocol packet is
         encapsulated in the PPP Information field, where the PPP
         Protocol field indicates type hex 80?? (Tag Switching).

      3. Code field

         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
         Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
         Ack and Code-Reject) are used.  Other Codes should be treated
         as unrecognized and should result in Code-Rejects.

      4. Timeouts

         Tag Switching Control Protocol packets may not be exchanged
         until PPP has reached the Network-Layer Protocol phase.  An
         implementation should be prepared to wait for Authentication
         and Link Quality Determination to finish before timing out
         waiting for a Configure-Ack or other response.  It is suggested
         that an implementation give up only after user intervention or
         a configurable amount of time.

      5. Configuration Option Types

         None.

Rosen, et al.                                                   [Page 6]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

3.3. Sending Tagged Packets

   Before any tagged packets may be communicated, PPP must reach the
   Network-Layer Protocol phase, and the Tag Switching Control Protocol
   must reach the Opened state.

   Exactly one tagged packet is encapsulated in the PPP Information
   field, where the PPP Protocol field indicates either type hex 00??
   (Tag Switching -- Unicast) or type hex 00?? (Tag Switching --
   Multicast).  The maximum length of a tagged packet transmitted over a
   PPP link is the same as the maximum length of the Information field
   of a PPP encapsulated packet.

   The format of the Information field itself is as defined in section
   2.

   Note that two codepoints are defined for tagged packets; one for
   multicast and one for unicast.  Once the TSCP has reached the Opened
   state, both tag switched multicasts and tag switched unicasts can be
   sent over the PPP link.

3.4. Tag Switching Control Protocol Configuration Options

   There are no configuration options.

4. Transporting Tagged Packets over LAN Media

   A pair of two byte ethertype values will be obtained, one
   representing "Tag Switching -- Unicast" and one representing "Tag
   Switching -- Multicast".

   These can be used with either the Ethernet encapsulation or the 802.3
   SNAP/SAP encapsulation to carry tagged packets.

   Exactly one tagged packet is carried in each frame.

   The Tag Stack Entries immediately precede the network layer header,
   and follow any data link layer headers, including any VLAN headers
   that may exist.

Rosen, et al.                                                   [Page 7]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

5. Security Considerations

   Security considerations are not discussed in this document.

6. Authors' Addresses

   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

   Dan Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

   Dino Farinacci
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: [email-masked]

   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: [email-masked]

   Guy Fedorkow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

Rosen, et al.                                                   [Page 8]


Internet Draft        draft-rosen-tag-stack-00.txt         November 1996

7. References

   [1] Tag Switching Architecture Overview, draft-rfced-info-rekhter-
   00.txt, Rekhter, Davie, Katz, Rosen, Swallow

Rosen, et al.                                                   [Page 9]

---

From: "PHILIP MATTHEWS" <[email-masked]>
Date: Mon, 01 Nov 1999 15:54:25 -0500

Eric:

Copy of draft-davie-tag-switching-atm-00.txt is attached.
Taken from our I-D archives.

- Philip Matthews
Newbridge Networks Corporation

Network Working Group                                        Bruce Davie
Internet Draft                                               Paul Doolan
Expiration Date: April 1997                              Jeremy Lawrence
                                                        Keith McCloghrie
                                                           Yakov Rekhter
                                                              Eric Rosen
                                                          George Swallow

                                                     Cisco Systems, Inc.

                                                            October 1996

                     Use of Tag Switching With ATM

                  draft-davie-tag-switching-atm-00.txt

Status of this Memo

Abstract

Davie, et al.                                                   [Page 1]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

   A tag switching architecture is described in [1].  Tag Switching
   enables the use of ATM Switches as Tag Switching Routers. The ATM
   Switches run network layer routing algorithms (such as OSPF, IS-IS,
   etc.), and their data forwarding is based on the results of these
   routing algorithms. No ATM-specific routing or addressing is needed.

   This document describes how the tag switching architecture is applied
   to ATM switches.

Contents

    1      Introduction  ...........................................   2
    2      Definitions  ............................................   3
    3      Tag Switching Control Component for ATM  ................   3
    4      Hybrid Switches (Ships in the Night)  ...................   4
    5      Use of  VPI/VCIs  .......................................   4
    6      Tag Allocation and Maintenance Procedures  ..............   5
    7      Encapsulation  ..........................................   6
    8      Security Considerations  ................................   7
    9      Intellectual Property Considerations  ...................   7
   10      References  .............................................   7
   11      Acknowledgments  ........................................   8
   12      Authors' Addresses  .....................................   8

1. Introduction

   A tag switching architecture is described in [1]. It is possible to
   use ATM switches as tag switching routers. Such ATM switches run
   network layer routing algorithms (such as OSPF, IS-IS, etc.), and
   their forwarding is based on the results of these routing algorithms.
   No ATM-specific routing or addressing is needed.

   When an ATM switch is used for tag switching, the tag on which
   forwarding decisions are based is carried in the VCI and/or VPI
   fields. (It is possible to carry multiple tags in the VCI and/or VPI
   fields, but the scope of this document is restricted to the case of a
   single tag.)

   The characteristics of ATM switches require some specialized
   procedures and conventions to support tag switching. This document
   describes those aspects of tag switching which are specific to ATM.

Davie, et al.                                                   [Page 2]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

2. Definitions

   A Tag Switching Router (TSR) is a device which implements the tag
   switching control and forwarding components described in [1].

   A tag switching controlled ATM (TC-ATM) interface is an ATM interface
   controlled by the tag switching control component. Packets traversing
   such an interface carry tags in the VCI and/or VPI field.

   An ATM-TSR is a TSR with a number of TC-ATM interfaces which forwards
   cells between these interfaces using tags carried in the VCI and/or
   VPI field.

   A frame-based TSR is a TSR which forwards complete frames between its
   interfaces. Note that such a TSR may have zero, one or more TC-ATM
   interfaces.

   An ATM-TSR cloud is a set of ATM-TSRs which are mutually
   interconnected by TC-ATM interfaces.

   The Edge Set of an ATM-TSR cloud is the set of frame-based TSRs which
   are connected to the cloud by TC-ATM interfaces.

3. Tag Switching Control Component for ATM

   To support tag switching an ATM switch must implement the control
   component of tag switching. This consists primarily of tag allocation
   and maintenance procedures. Tag binding information is communicated
   through the Tag Distribution Protocol (TDP) [2].

   Since the tag switching control component uses information learned
   directly from network layer routing protocols, this implies that the
   switch must participate as a peer in these protocols (e.g., OSPF,
   IS-IS).

   Support of tag switching on an ATM switch does not require the switch
   to support the ATM control component defined by the ITU and ATM Forum
   (e.g., UNI, PNNI). An ATM-TSR may optionally respond to OAM cells.

Davie, et al.                                                   [Page 3]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

4. Hybrid Switches (Ships in the Night)

   The existence of the tag switching control component on an ATM switch
   does not preclude the ability to support the ATM control component
   defined by the ITU and ATM Forum on the same switch and the same
   interfaces.  The two control components, tag switching and the
   ITU/ATM Forum defined, would operate independently.

   Definition of how such a device operates is beyond the scope of this
   document.  However, only a small amount of information needs to be
   consistent between the two control components, such as the portions
   of the VPI/VCI space which are available to each component.

5. Use of  VPI/VCIs

   Tag switching is accomplished by associating tags with routes and
   using the tag value to forward packets, including determining the
   value of any replacement tag.  See [1] for further details. In an
   ATM-TSR, the tag is carried in the VPI and/or VCI field. Just as in
   ATM, for a cell arriving at an interface, the VPI/VCI is looked up,
   replaced, and the cell is switched.

   ATM-TSRs may be connected by ATM virtual paths to enable
   interconnection of ATM-TSRs over a cloud of conventional ATM
   switches. In this case, the tag is carried in the VCI field.

   For two connected ATM-TSRs, a connection must be available for TDP.
   The default is for this connection to be on VPI 0, VCI 32. For ATM-
   TSRs connected by a VPI of value x, the default for the TDP
   connection is VPI x, VCI 32. Additionally, for all VPI values, VCIs 0
   - 32 are not used as tags.

   With the exception of these reserved values, the VPI/VCI values used
   in the two directions of the link may be treated as independent
   spaces.

   The allowable ranges of VPI/VCIs are always communicated through TDP.
   If more than one VPI is used for tag switching, the allowable range
   of VCIs may be different for each VPI, and each range is communicated
   through TDP.

Davie, et al.                                                   [Page 4]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

6. Tag Allocation and Maintenance Procedures

   ATM-TSRs use the downstream-on-demand allocation mechanism described
   in [1]. The procedures for tag allocation are as follows.

   Consider a member of the Edge Set of an ATM-TSR cloud. Assume that,
   as a result of its routing calculations, it selects an ATM-TSR as the
   next hop of a certain route, and that the next hop is reachable via a
   TC-ATM interface. The Edge TSR uses TDP's BIND_REQUEST to request a
   tag binding from the next hop.  The hop count field in the request is
   set to 1.  Once the Edge TSR receives the tag binding information,
   the tag is used as an outgoing tag.

   When an ATM-TSR receives (via TDP) a tag binding request for a
   certain route from a peer connected to the ATM-TSR over a TC-ATM
   interface, the ATM-TSR allocates a tag, creates a new entry in its
   Tag Information Base (TIB), places that tag in the incoming tag
   component of the entry, and returns (via TDP) a binding containing
   the allocated tag back to the peer that originated the request.  The
   ATM-TSR then requests (via TDP) a tag binding from the next hop for
   that route. The hop count field in the request that the ATM-TSR sends
   (to the next hop TSR) is set to the hop count field in the request
   that the ATM-TSR received (from the upstream TSR) plus one.  Once the
   ATM-TSR receives the binding from the next hop, the ATM-TSR places
   the tag from the binding into the outgoing tag component of the TIB
   entry.

   When a member of the Edge Set of the ATM-TSR cloud receives a tag
   binding request from an ATM-TSR, it allocates a tag, creates a new
   entry in its Tag Information Base (TIB), places that tag in the
   incoming tag component of the entry, and returns (via TDP) a binding
   containing the allocated tag back to the peer that originated the
   request.  It uses the hop count that it received in the tag binding
   request from the previous hop to adjust the TTL of packets that
   arrive from that hop carrying this tag.

   Note that an ATM-TSR, or a member of the edge set of an ATM-TSR
   cloud, may receive multiple binding requests for the same route from
   the same ATM-TSR. It must generate a new binding for each request
   (assuming adequate resources to do so), and retain any existing
   binding(s). For each request received, an ATM-TSR should also
   generate a new binding request toward the next hop for the route.

   When a routing calculation causes an ATM-TSR or a member of the edge
   set of an ATM-TSR cloud to change the next hop for a route, the ATM-
   TSR should notify the former next hop (via TDP) that the tag binding
   associated with the route is no longer needed.

Davie, et al.                                                   [Page 5]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

   When a TSR receives a notification that a particular tag binding is
   no longer needed, the TSR may deallocate the tag associated with the
   binding, and destroy the binding. In the case where an ATM-TSR
   receives such notification and destroys the binding, it should notify
   the next hop for the route that the tag binding is no longer needed.
   If a TSR does not destroy the binding, it may re-use the binding only
   if it receives a request for the same route with the same hop count
   as the request that originally caused the binding to be created.

   When a route changes, the tag bindings are re-established from the
   point where the route diverges from the previous route.  TSRs
   upstream of that point are oblivious to the change.  Whenever a TSR
   changes its next hop for a particular route, if the new next hop is
   an ATM-TSR or a member of the edge set reachable via a TC-ATM
   interface, then for each entry in its TIB associated with the route
   the TSR should request (via TDP) a binding from the new next hop.

   Whenever an ATM-TSR originates a tag binding request to its next hop
   TSR as a result of receiving a tag binding request from another
   (upstream) TSR, and the request to the next hop TSR is not satisfied,
   the ATM-TSR should destroy the binding created in response to the
   received request, and notify the requester (via TDP).

   If an ATM-TSR receives a binding request containing a hop count that
   equals MAX_HOP_COUNT, no binding should be established and an error
   message should be returned to the requester.

   When a TSR determines that it has lost its TDP session with another
   TSR, the following actions are taken.  Any binding information
   learned via this connection must be discarded.  For any tag bindings
   that were created as a result of receiving tag binding requests from
   the peer, the ATM-TSR may destroy these bindings (and deallocate tags
   associated with these binding).

7. Encapsulation

   By default, all tagged packets should be transmitted with the generic
   tag encapsulation, as defined in [3]. Since the value at the top of
   the tag stack is determined from the VCI and/or VPI fields, the
   generic encapsulation contains n-1 tags for a tag stack of depth n.
   This means that for one level of tags the generic encapsulation
   consists of a tag leader only.

   For systems which are using only one level of tagging, TDP may be
   used to negotiate null encapsulation.  This negotiation is done once
   at TDP open and applies to all VPI/VCI values used as tags. In this
   case, IP packets are carried directly inside AAL5 frames, as in the

Davie, et al.                                                   [Page 6]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

   null encapsulation of RFC 1483.

   The initial TDP connection, described in Section 5, uses the LLC/SNAP
   encapsulation, as defined in Section 4.1 of RFC1483. This same VCI
   (with the LLC/SNAP encapsulation) may be used to exchange Network
   Layer routing information as well.

   TDP may be used to advertise additional VPI/VCIs to carry control
   information or non-tagged packets. These may use either the null
   encapsulation, as defined in Section 5.1 of RFC1483, or the LLC/SNAP
   encapsulation, as defined in Section 4.1 of RFC1483.

8. Security Considerations

   Security considerations are not addressed in this document.

9. Intellectual Property Considerations

   Cisco Systems may seek patent or other intellectual property
   protection for some or all of the technologies disclosed in this
   document. If any standards arising from this document are or become
   protected by one or more patents assigned to Cisco Systems, Cisco
   intends to disclose those patents and license them on reasonable and
   non-discriminatory terms.

10. References

   [1] Rekhter, Y. et al. Tag Switching Architecture Overview, Internet
   Draft, draft-rfced-info-rekhter-00.txt, Sept. 1996.

   [2] Doolan, P. et al. Tag Distribution Protocol, Internet Draft,
   draft-doolan-tdp-spec-00.txt, Sept. 1996.

   [3] Rosen, E. et al. Tag Switching: Tag Stack Encodings, Internet
   Draft, Oct. 1996.

Davie, et al.                                                   [Page 7]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

11. Acknowledgments

   Significant contributions to this work have been made by Anthony
   Alles, Fred Baker, Dino Farinacci, Guy Fedorkow,  Arthur Lin, Morgan
   Littlewood and Dan Tappan.

12. Authors' Addresses

   Bruce Davie
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

   Paul Doolan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

   Jeremy Lawrence
   Cisco Systems, Inc.
   1400 Parkmoor Ave.
   San Jose, CA, 95126

   E-mail: [email-masked]

   Keith McCloghrie
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: [email-masked]

   Yakov Rekhter
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

   E-mail: [email-masked]

Davie, et al.                                                   [Page 8]

Internet Draft    draft-davie-tag-switching-atm-00.txt      October 1996

   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824

   E-mail: [email-masked]

Davie, et al.                                                   [Page 9]