Internet Draft 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 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). 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: bsd@cisco.com Paul Doolan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: pdoolan@cisco.com Jeremy Lawrence Cisco Systems, Inc. 1400 Parkmoor Ave. San Jose, CA, 95126 E-mail: jlawrenc@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: kzm@cisco.com Yakov Rekhter Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: yakov@cisco.com 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: erosen@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 E-mail: swallow@cisco.com Davie, et al. [Page 9]