Internet Draft Comparison of Tag Switching and CSR April, 1997 Multi-Protocol Label Switching WG Yoshihiro Ohba Internet Draft Toshiba Expiration Date: October 1997 Hiroshi Esaki Toshiba Yasuhiro Katsube Toshiba April 1997 Comparison of Tag Switching and Cell Switch Router draft-ohba-tagsw-vs-csr-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 Tag Switching and Cell Switch Router are layer integration technologies between L2 and L3 to provide high-speed cut-through mechanisms for L3 packet transfer by mapping between L3 and L2 datagram labels. TDP and FANP, used in Tag Switching and Cell Switch Router, respectively, are protocols that notify the mapping information between peer routers. Although the objectives of both technologies are the same, there are several differences in methods for achieving the objective. This memo compares the two technologies and discusses how to merge them. 1. Tag Switching In Tag Switching, the mapping is called binding, and the binding is uniquely identified by 32-bit fixed length index called tag. Tags are Y.Ohba, et al. Expires October, 1997 [Page 1] Internet Draft Comparison of Tag Switching and CSR April, 1997 allocated based mainly on destination address to support destination-based routing (of course Tag Switching can support other allocation policies). A destination-based binding is created when the routing protocol running on the TSR creates a new routing table entry. This type of allocation is called "control-traffic-driven." As for tag allocation, Tag Switching allows three modes: downstream tag allocation, downstream tag allocation on demand, and upstream tag allocation. Downstream tag allocation on demand is currently defined for supporting ATM. Hereafter we focus on downstream on demand for the purpose of discussion on tag management over ATM. See [1] for other modes. Tag Switching uses two methods for advertising the mapping between L2 and L3 labels. One method is using existing protocol packets, i.e., tags are carried in the protocol messages such as BGP, PIM, and RSVP [2] messages. The other method is using Tag Distribution Protocol (TDP) [3] which is the specialized protocol for distributing tags. TDP is used where the former method is not efficient (e.g., an OSPF area). TDP runs between two Tag Switching Routers (TSRs) over a connection oriented transport layer with guaranteed sequential delivery (e.g., TCP). In other words, one TDP session is established between peer TSRs. A TDP session is kept by sending keep-alive packets periodically to its peer. If a TDP does not see keep-alive packets from its peer within certain interval, the TDP session is deleted. In ATM environment, a tag information exchanged (via TDP) between peer TSRs contains a VPI/VCI of cell header [4], which puts a restriction on Tag Switching that a TSR is not allowed to connect its peer via conventional ATM switches since VPI/VCI is re-written at each ATM switch. When ATM-TSR receives a tag binding request for a certain route from an upstream neighbor ATM-TSR, it creates the binding between incoming tag (VPI/VCI) and the route, and advertises them to the peer that originated the request. The ATM-TSR then requests for an outgoing tag (VPI/VCI) to the next hop for that route. After receiving the binding from the next hop neighbor, the ATM-TSR associates the incoming tag with the outgoing tag, which enables cut-through packet forwarding. Once a binding is created, it is not deleted as long as the route for the corresponding destination is kept unchanged or the TDP session is alive. If a new binding request for a route arrives and there are already some binding(s) for the same route, the ATM-TSR must create a new different incoming tag for the same route and request for a different outgoing tag. This is because packets which have the same destination Y.Ohba, et al. Expires October, 1997 [Page 2] Internet Draft Comparison of Tag Switching and CSR April, 1997 but arrived at different input interfaces cannot be multiplexed onto a single VC unless some non-interleaving scheduling mechanism is supported in the underlying L2 switch. As a result, the bindings are created for each (ingress-TSR, destination address prefix). When a tag binding is no longer needed, the ATM-TSR may delete the binding and notify the next hop. Then the next hop ATM-TSR also destroy the corresponding binding and notify the next hop, and this process is repeated at each ATM-TSR. In this point, we can say that globally synchronized (end-to-end) states are maintained by using TDP. Tag Switching also allows a packet to carry a set of tags, organized as a stack [1,5]. Each tag in a stack corresponds to each routing hierarchy, e.g., BGP and IGP. This enables Tag Switching to scale. 2. Cell Switch Router (CSR) In CSR [8], FANP (Flow Attribute Notification Protocol) [6] plays the same role as TDP in Tag Switching. FANP runs between two CSRs over unreliable transport (the current FANP implementation runs over IP with unreserved protocol-id). No FANP level session is established between peer CSRs. To identify the mapping between L3/L2 labels, a CSR allocates a VCID (Virtual Connection IDentifier). FANP can support various types (lengths) of VCIDs depending on L2. Fixed length (12-octet) VCID is defined for ATM, which is composed of 6-octet ESI (End System Identifier) of an ATM end-system address, and 6-octet ID which uniquely identifies VCIDs allocated by the same CSR. The use of VCID instead of VPI/VCI makes CSR independent of topological design. This means that, with VCID negotiation procedure, CSRs can be interconnected through the ATM switches that changes incoming VPI/VCI values to the different outgoing VPI/VCI values. VCIDs are uniquely allocated based mainly on a pair of IP source and destination addresses. We refer to such a pair as a flow. The allocation is made when the first trigger packet arrives. Trigger packet is a packet which contains one of certain TCP/UDP port numbers and certain address pair. This type of allocation is called "data-traffic-driven." As for the VCID management over ATM, current FANP specification supports upstream VCID allocation policy, e.g., after allocating a VCID a CSR advertises the VCID and the corresponding (source, destination) pair to the downstream neighbor CSR, and the receiving CSR installs these information. Since the current CSR implementation is flow-based, the receipt of incoming VCID does not trigger off a new allocation of an outgoing VCID at the receiving CSR. Instead, allocations are always triggered by arrivals of trigger packets. Y.Ohba, et al. Expires October, 1997 [Page 3] Internet Draft Comparison of Tag Switching and CSR April, 1997 After the mapping information for the flow is installed at the downstream CSR, the CSR periodically sends refresh packets to the upstream neighbor as long as there are any packet arrivals for that flow in each period. Refresh packets are sent flow-by-flow. The interval used to send refresh packets is called RefreshInterval. If no data packet arrives within N*RefreshInterval, the mapping information created for the incoming flow and the incoming VC for that flow are deleted. The upstream CSR sets a timer on receiving the first refresh packet from its downstream neighbor. The timer is called Dead Timer, and the value set to Dead Timer is called DeadInterval. The upstream CSR keeps the outgoing VC and the mapping information for that flow as long as it receives a refresh packet from the downstream neighbor before Dead Timer expires. Dead Timer is always reset on receiving a refresh packet before expiration of Dead Timer. If no refresh packet is received within DeadInterval, the CSR deletes the outgoing mapping information and release the outgoing VC for that flow. This means that CSR employs a soft state mechanism in mapping management. Note that our implementation also allows state deletion at any time when a CSR receives a release packet from its downstream neighbor. Unlike Tag Switching, deletion of a state (mapping) for a flow is executed locally, without notifying the deletion that would cause the deletion of entire states for the flow along the path. Hence we can say that local (link-by-link) states are maintained by using FANP. Y.Ohba, et al. Expires October, 1997 [Page 4] Internet Draft Comparison of Tag Switching and CSR April, 1997 Table 1: Comparison of Tag Switching and CSR +-------------------+-------------------------+---------------------------+ | | Tag Switching | CSR | +===================+=========================+===========================+ | Method for | (1) use existing | | | binding info. | protocol packets | use FANP | | delivery | (2) use TDP | | +-------------------+-------------------------+---------------------------+ | Trigger to create | Route change | Arrival of trigger packet | | a state |(control-traffic-driven) | (data-traffic-driven) | +-------------------+-------------------------+---------------------------+ | Unit of state | (ingress-TSR,dst) | (src,dst) | +-------------------+-------------------------+---------------------------+ | Impact of | Not local | Local | | state change | (when TDP is used) | | +-------------------+-------------------------+---------------------------+ | Consistency with | Both deletes old binding immediately | | routing state | when routing state changes. | +-------------------+-------------------------+---------------------------+ | Binding allocation| downstream allocation | upstream allocation only | | policy | (in most cases) | | +-------------------+-------------------------+---------------------------+ | How to deal with | Loop prevention by using| Loop correction | | loops | TDP hopcount or TTL | | | | field in tag stack | | +-------------------+-------------------------+---------------------------+ | Hierarchy support | Yes | No | +-------------------+-------------------------+---------------------------+ 3. Comparison We summarize the features of Tag Switching and CSR in ATM environment in Table 1. 3.1 Method for binding information delivery There are two methods for Tag Switching to deliver binding information: (1) using existing protocol packets, and (2) using TDP. When method (1) is used, reliability of delivery is realized by the carrying protocol. When method (2) is used, TCP guarantees the reliability. On the contrary, CSR always uses FANP for the binding information delivery. FANP has its own reliable delivery mechanism, used in common with unicast and multicast, over unreliable transport. 3.2 Trigger to create a state Y.Ohba, et al. Expires October, 1997 [Page 5] Internet Draft Comparison of Tag Switching and CSR April, 1997 Installation of state with the current CSR is driven by data traffic for the legacy packet traffic. The operation overview for RSVP traffic is given in [7]. In contrast installation of state with tag switching is driven directly by control traffic (e.g., unicast routing updates, RSVP messages, PIM messages). 3.3 Unit of state In CSR, a state is created for (src, dst). In Tag Switching, a state is created for (ingress TSR, dst). 3.4 Impact of state change When a state change occurs in a TSR with TDP, it causes direct state changes at other TSRs (e.g., by sending TDP_PIE_REMOVE_BIND messages). So, if a TDP session fails in some node, say A, for some reason, the entire bindings for all routes that go through node A are completely deleted from the network and only hop-by-hop packet transfer is permitted for those routes, unless VC merging is not available. On the contrary, changes in state with CSR are purely local, default-VC (hop-by-hop) transfer is carried out only between node A and its neighbor routers. 3.5 Consistency with routing state When a routing state changes, both Tag Switching and CSR immediately deletes the old bindings associated to the change, and creates new bindings according to the new routing state. 3.6 Binding allocation policy As for binding allocation, Tag Switching employs downstream allocation policy in most cases whereas CSR employs upstream allocation policy. However, downstream allocation seems inapplicable to multicast cut-through on multi-access ATM network using the standard ATM Forum/ITU-T signaling. 3.7 Loop detection There are two methods to deal with loops over label switching path: loop correction and loop prevention. In the loop correction, MPLS level loops are allowed to be set up over a label switching path, and data may be transmitted over the loops, but the loops is later detected and closed. On the contrary, in the loop prevention, data is never transmitted over a MPLS level loop. CSR has a loop correction mechanism in which MPLS level loops disappear as soon as the related L3 level loops disappear. Tag Switching has two loop prevention mechanisms. Y.Ohba, et al. Expires October, 1997 [Page 6] Internet Draft Comparison of Tag Switching and CSR April, 1997 One method is using TDP level hop count which is carried in TDP messages. Another method is using TTL field of tag stack which is prepended to each IP packet [5]. 3.8 Hierarchy support The idea of hierarchical tag support in Tag Switching is good in terms of scalability. References [1] Y. Rekhter et al., "Cisco System's Tag Switching Architecture Overview," Internet RFC 2105, Feb. 1997. [2] F. Baker, "Use of Flow Label for Tag Switching," Internet Draft, draft-baker-flow-label-00.txt, Oct. 1996. [3] P. Doolan et al., "Tag Distribution Protocol," Internet Draft, draft-doolan-tdp-spec-00.txt, Sep. 1996. [4] B. Davie et al., "Use of Tag Switching With ATM," Internet Draft, draft-davie-tag-switching-atm-01.txt, Jan. 1997. [5] E. Rosen et al., "Tag Switching: Tag Stack Encodings," Internet Draft, draft-rosen-tag-stack-01.txt, March 1997. [6] K. Nagami et al., "Flow Attribute Notification Protocol (FANP) Specification," Internet Draft, draft-rfced-info-nagami-00.txt, Nov. 1996. [7] Y. Katsube et al., "Interoperation Scenario Between Distinct Types of Cut-through," Internet Draft, Apl. 1997. [8] Y. Katsube et al., "Toshiba's Router Architecture Extensions for ATM : Overview", Internet RFC 2098, Feb. 1997. Y.Ohba, et al. Expires October, 1997 [Page 7] Internet Draft Comparison of Tag Switching and CSR April, 1997 Authors Yoshihiro Ohba R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Tel: +81-44-549-2238 Fax: +81-44-520-1806 Email: ohba@csl.rdc.toshiba.co.jp Hiroshi Esaki Computer and Network Division, Toshiba Corporation, 1-1-1 Shibaura, Minato-ku, 105-01, Japan. Tel: +81-3-3457-2536 Fax: +81-3-5444-9234 Email: hiroshi@isl.rdc.toshiba.co.jp Yasuhiro Katsube R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Tel: +81-44-549-2238 Fax: +81-44-520-1806 Email: katsube@isl.rdc.toshiba.co.jp Acknowledgment We appreciate Yakov Rekhter and Paul Doolan of Cisco Systems Inc. for giving us comments on this document.